пт, 9 авг. 2024 г. в 03:36, Niall Douglas via Boost
On Wed, Aug 7, 2024 at 4:04 PM Jeff Trull via Boost
wrote: I would much rather that the maintainer of the library inlines the visualisers for their library, and then maintains them over time as On 08/08/2024 17:56, Vinnie Falco via Boost wrote: 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.