On 10/16/18 4:14 AM, Vinnie Falco via Boost wrote:
On Mon, Oct 15, 2018 at 11:00 AM James E. King III via Boost
wrote: In the winapi project there's a neat little Jamfile rule that will ensure each public header will compile properly (i.e. it is not missing any #include statements).
This makes it harder for package managers to build the tests using their desired toolchain, since the bjam portions must be ported. I realize of course this might be a purely theoretical problem before the arrival of the much-heralded "modular boost." I copy Asio's style and include the header first in the test .cpp file, and if there are no tests then I have an empty .cpp file which still includes the header:
https://github.com/boostorg/beast/blob/ec1c8ada7a22b274cf6e58c019c2bbe6965f6...
This way if someone compiles the tests with a different system, they will still get the checks to ensure that headers build by themselves, without resorting to fancy build system plugins.
The Jamfile code snippet is not a plugin but is a part of the testing script. Given that Boost library testing is currently done with Boost.Build, if one want to do the testing with another build system, he would have to port that script in its entirety anyway. It doesn't really matter whether the tests are generated by scanning the filesystem or are spelled out explicitly; in the former case it might be even less manual labor.