Package these printers so they're present by default

[pfee]

Has any work been done on packaging this project for inclusion within distros (e.g. Fedora)?

On Fedora, the libstdc++ package already includes the STL pretty printers.

$ rpm -ql libstdc++-4.8.3-7.fc20.x86_64 | grep gdb.py$ /usr/share/gdb/auto-load/usr/lib64/libstdc++.so.6.0.19-gdb.py

It would be helpful if the same approach was taken for the boost pretty printers here.

I expect this is something for the downstream distros to do, however if you could even state whether the distros are aware of this project that would help. If they are, what's the status?

If not, we could then raise a packaging request with downstream. Getting this packaged would help get it into the hands of more users.

[ruediger]

Actually when I started it, I hoped it would eventually move upstream into Boost and thus be automatically packaged. But I stopped actively developing it besides merging patches. So I never took the time to talk to the Boost guys about it. It could of course be packaged externally as well.

I'd like to hand over the printers to someone else for maintenance.

[pfee]

Moving upstream into Boost sounds like a better idea than separate packaging. That way all Boost users should get it eventually. I was pleased to stumble across this project as it made debugging boost::optional usage much easier - thank you!

Is there anything that needs done before trying to push this code upstream? If it's ready to go already, let's start that process.

[ruediger]

I guess having an active maintainer would be required. I don't know what the boost guys expect besides that. I have never spoke to them about it.

[pfee]

I've signed up to the boost-devel mailing list and asked about getting this code included.

[ruediger]

Thanks!

[mateidavid]

I guess there were no replies on the boost devel list, right?

[pfee]

Correct, I'm afraid there were no replies to my post: http://thread.gmane.org/gmane.comp.lib.boost.devel/255375

You're welcome to try again and help push this along. Having these pretty printers bundled with Boost and/or distro packages would allow them be discovered and used much more.

[mateidavid]

Oh, I agree, it's just that by nature (relying on implementations, not just API) they are a bit of a nightmare to maintain.

[apolukhin]

Sorry for the late response.

So, here's my plan how to integrate those printers into Boost:

• separate the one big printer into multiple printers for each Boost library
• make a root script that installs the printers from libs/*/debuggers/ folder to the system
• push to root Boost project that root script
• push to each library separately a printer
• PROFIT

There's another project, close to this one, but for Visual Studio: https://github.com/KindDragon/CPPDebuggerVisualizers For that project the instructions would be almost the same.

If no one objects, that I'll write a mail to Boost mailing list describing this proposal and will help you to cope with Boost internals.

[mateidavid]

It would be great news to have these packaged with boost.

In my latest pull request I took the first steps towards modularizing them. I'm still using a master "utilities" module, but apart from that, printers can now be easily separated into modules.

I have a few questions:

1. Regarding multiple printer versions. As I explained in the pull request comment and the HACKING.org document I added to the pull request, it might be beneficial to have not one, but several printers available (so that older ones can be enabled if needed). Within your framework, would this be done by having, e.g., several intrusive priner versions somewhere under intrusive/debugging?
2. Compared to the bulk of the Boost code, the printers are best qualified as "experimental". This is not to say they are badly written, just that they were written when needed, so they are not comprehensive in any way. Also, because they lack a rigurous testing suite, occasional python exceptions arise. Heavy users might know how to find the problem within 2 minutes, but a random Boost user might not have that kind of experience. Would this "experimental" nature be a problem when it comes to potential inclusion?
3. The project doesn't have a dedicated maintainer. Would that be an issue with Boost? Without a maintainer, the printers would easily get out-of-date.