Page MenuHomeFreeBSD

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

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



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

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

Diff Detail

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

Event Timeline

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

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.
15 ↗(On Diff #53608)

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

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 inline comments.
15 ↗(On Diff #53608)

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

15 ↗(On Diff #53608)

Except it won't work if you build GDB without python support (hence why it depends on the 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.

  • 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.

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

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?

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

  • Merge into devel/gdb port under the python option.
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.