This is the mail archive of the archer@sourceware.org mailing list for the Archer project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: FYI: removing the libstdc++ pretty-printers


>>>>> "Paul" == Paul Pluzhnikov <ppluzhnikov@google.com> writes:

Paul> Given that we don't want to have full GDB tests which check that
Paul> STL pretty printers work (for fear of libstdc++ implementation
Paul> changing underneath us), and libstdc++ can't test these printers
Paul> at all (they'd need a capable GDB to do so, which isn't going to
Paul> be generally available for a while), who is going to maintain
Paul> these printers at all?

Yeah, we didn't write tests for libstdc++.  We really ought to.  We
can easily make a test conditional on whether gdb supports the
feature.

The libstdc++ maintainers will be maintaining this code.  I think one
of them already has some changes waiting.  In practice I expect
someone from Archer (me :-) will end up making fixes as well.

Paul> Since the printers are versioned, and (AFAIU) libstdc++
Paul> implementation can not change in v6 (that would break binary
Paul> compatibility), would it not be better for us to maintain
Paul> libstdcxx/v6/printers.py (especially given that any required
Paul> maintenance would likely be due to GDB/Python internals changes,
Paul> not libstdc++.so.6 changes).

I didn't really spell out my full argument.

I want and expect this feature to be very widely used, as in, have a
suite of pretty printers for every library and application shipped in
the OS.

I think the only way to manage this sanely is for library and
application maintainers to agree to maintain the printers.

Now, the libstdc++ printers are special in that they are the flagship
implementation and they are the most-requested printers.  But, I think
it is a good idea for us to use these as an example along all the
available axes -- not just how they are implemented, but also how they
are maintained and distributed.  I think this is a good idea first
because it provides a working example to other users wanting to write
their own printers, and second because it lets us flush out any
remaining problems in our approach.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]