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

[jhb]

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.

[jhb]

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

[bdrewery]

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]

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]

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]

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]

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

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

[jhb]

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]

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]

• Merge into devel/gdb port under the python option.

[pizzamig]

Looks Good To Me