Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Package these printers so they're present by default #18

Open
pfee opened this issue Nov 13, 2014 · 10 comments
Open

Package these printers so they're present by default #18

pfee opened this issue Nov 13, 2014 · 10 comments

Comments

@pfee
Copy link

pfee commented Nov 13, 2014

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
Copy link
Owner

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
Copy link
Author

pfee commented Nov 17, 2014

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
Copy link
Owner

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
Copy link
Author

pfee commented Nov 18, 2014

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

@ruediger
Copy link
Owner

Thanks!

@mateidavid
Copy link
Collaborator

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

@pfee
Copy link
Author

pfee commented Mar 9, 2015

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
Copy link
Collaborator

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
Copy link

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
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants