пт, 9 авг. 2024 г. в 03:36, Niall Douglas via Boost <boost@lists.boost.org>:
On 08/08/2024 17:56, Vinnie Falco via Boost wrote:
On Wed, Aug 7, 2024 at 4:04 PM Jeff Trull via Boost <boost@lists.boost.org> wrote: I would much rather that the maintainer of the library inlines the visualisers for their library, and then maintains them over time as their library changes.
To make this work well, what we really need and don't have is a visualiser testing framework i.e. unit tests will fail if your visualiser stops matching your C++.
In my WIP GDB pretty printer branch I have the basis for GDB pretty printers tests. The "framework" consists of 1) an executable that creates objects to print and has labels at which to print (https://github.com/boostorg/json/pull/733/files#diff-61c3f2894b149b936ad8386...), 2) a Python script that makes GDB jump to labels and print expressions (https://github.com/boostorg/json/pull/733/files#diff-61c3f2894b149b936ad8386...), 3) b2 script to make that work from b2 (https://github.com/boostorg/json/pull/733/files#diff-2cde2bed13578c1217b5047...). This in theory could be turned into something more reusable.