Page MenuHomeFreeBSD

[new port] devel/libcxx-gdb: libc++ pretty printers for GDB.
ClosedPublic

Authored by jhb on Feb 5 2019, 7:03 PM.

Details

Summary

This makes it easier to debug C++ programs with GDB. The set of
supported STL classes is minimal currently but should grow over
time.

Test Plan
  • used these when debugging GDB itself which uses classes like std::unique_ptr, etc.

Diff Detail

Repository
rP FreeBSD ports repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

jhb created this revision.Feb 5 2019, 7:03 PM
linimon retitled this revision from Add a port for libc++ pretty printers for GDB. to [new port] devel/libcxx-gdb: libc++ pretty printers for GDB..Feb 7 2019, 11:07 AM
jhb added a subscriber: pizzamig.Feb 8 2019, 9:17 PM

Arguably the dependency should perhaps go the other way with the GDB port having an option to install this package as a dependency.

bdrewery added inline comments.
devel/libcxx-gdb/Makefile
15 ↗(On Diff #53608)

This port installs .py files and depends on a .py file, you need USES=python I believe.

jhb added inline comments.Feb 8 2019, 9:57 PM
devel/libcxx-gdb/Makefile
15 ↗(On Diff #53608)

So it's kind of different. One doesn't run these files directly. Instead, the embedded python interpreter in GDB runs them. So for example I can't directly depend on a python version in this port because I don't know which one will be used (and the scripts have to work with either v2 or v3 since GDB can be built with either one).

lwhsu added a subscriber: lwhsu.Feb 9 2019, 10:52 AM
lwhsu added inline comments.
devel/libcxx-gdb/Makefile
15 ↗(On Diff #53608)

Then I would suggest just using gdb>0:devel/gdb to declare this port depends on gdb.

jhb added inline comments.Feb 11 2019, 5:40 PM
devel/libcxx-gdb/Makefile
15 ↗(On Diff #53608)

Except it won't work if you build GDB without python support (hence why it depends on the xmethod.py file explicitly). But, the more I think about it, the more I think that it would be better to have the dependency the other way around: where devel/gdb would RUN_DEPENDS on this port if python support is enabled and the base OS is using libc++ so that working STL things is just transparent to the user.

jhb updated this revision to Diff 53812.Feb 11 2019, 11:44 PM
  • Rename port to devel/libcxx-gdbpy to match github repository. This also makes %%DATADIR%% patch the data directory perfectly simplifying the plist.
  • Remove one layer of directories in the installed tree.
  • Reverse the dependency with regards to gdb by making devel/gdb depend on this port if python is enabled in the gdb build. This means that folks installing gdb will get libc++ helpers out of the box on platforms using libc++. This assumes that these helpers are useful.
pizzamig requested changes to this revision.Feb 12 2019, 10:23 AM

What do you think if, instead of creating a new port, just add those files to devel/gdb? It would solve any python/gdb dependencies and you'll get the .pyc managed for free.
We can use the gdb portrevision to manage libcxx updates..
I can prepare a patch to modify gdb if you're OK with it

This revision now requires changes to proceed.Feb 12 2019, 10:23 AM
jhb added a comment.Feb 12 2019, 4:40 PM

The only reason I have it separate is that I anticipate (hope) that it will change more quickly than gdb if other people contribute more pretty printers, etc. (It only covers a few STL classes now and has large gaps) Having a separate port just means people can update that package independently. That said, the .pyc thing (in case you run gdb as root against a C++ program) is a valid point (and one that can't really be solved as a separate port), and probably there just won't be but so many port revision bumps. I don't mind moving it into devel/gdb. Would you want it as a separate option (that "implies" python in ports speak) or just have it be part of the existing python option?

pizzamig added a comment.EditedFeb 12 2019, 4:58 PM

it can be part of the python option
Having those python extension inside the gdb port looks easier to me, at least for now
We'll use the portrevision to force the update of the package when only this external component got an update.
If we'll have daily releases, we'll re-consider the idea of a separate port

jhb updated this revision to Diff 53877.Feb 13 2019, 5:29 PM
  • Merge into devel/gdb port under the python option.
pizzamig accepted this revision.Feb 15 2019, 4:10 PM

Looks Good To Me

This revision is now accepted and ready to land.Feb 15 2019, 4:10 PM
This revision was automatically updated to reflect the committed changes.