This makes it easier to debug C++ programs with GDB. The set of
supported STL classes is minimal currently but should grow over
time.
Details
Details
- Reviewers
pizzamig - Commits
- rP493008: Include pretty printers for libc++ when Python is enabled.
- used these when debugging GDB itself which uses classes like std::unique_ptr, etc.
Diff Detail
Diff Detail
- Repository
- rP FreeBSD ports repository
- Lint
No Lint Coverage - Unit
No Test Coverage - Build Status
Buildable 22483 Build 21637: arc lint + arc unit
Event Timeline
Comment Actions
Arguably the dependency should perhaps go the other way with the GDB port having an option to install this package as a dependency.
| 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. |
| 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). |
| 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. |
| 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. |
Comment Actions
- 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.
Comment Actions
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
Comment Actions
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?
Comment Actions
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