From: Jeff Trull (edaskel_at_[hidden])
Date: 2020-07-17 18:48:58
On Wed, Jul 15, 2020 at 10:11 AM Jeff Garland <azswdude_at_[hidden]> wrote:
> 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.