On Wed, Jul 15, 2020 at 10:11 AM Jeff Garland
Maybe we could encourage the author to bring it to us as a 'tool' -- I don't know that we need a review for that even. Regardless, I wasn't aware of these -- cool!
What concerns me about this approach is that the pretty-printers will quickly drift out of sync with the libraries themselves. In fact it has already happened - if you look at Rüdiger's repo you can see he had to incorporate a versioning scheme, as well as unit tests, to ensure the code stayed correct (one of the features I really like about his work). Some method where individual libraries produced visualizers that were combined at install time would be ideal, as they would be owned by each maintainer.
I think a good starting point would simply be to say "if you want to supply pretty-printers, please put them in XX directory in your library and use the following conventions". The work of producing a single resource for all of Boost could wait until a few libraries had started maintaining these. Off the top of my head, how about lib/XXX/debug/gdb/pp, where pp becomes the Python module, analogous to what on my system is /usr/share/gcc-10/python/libstdcxx/v6/, the top level libstdc++ pretty-printer? Similar work could be done, if desired, for VSCode and lldb, in parallel directories. Best, Jeff T.