On Tue, 16 Oct 2018 at 13:41, James E. King III via Boost
On Tue, Oct 16, 2018 at 4:41 AM Andrey Semashev via Boost
wrote: 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.
I genericized it a little and put it into a PR in logic https://github.com/boostorg/logic/pull/12, however this logic looks like it could make it into Boost.Build as a utility or two (one for test-expected-failures to build everything inside "compile-fail/", one for test-header-isolation that locates every header in the repository include/ path and does an isolation include test on it.
IMHO, a generic rule should rather accept list of headers instead of glob-ing them within a hardcoded location. I imagine users of the rule may wish to test subset of headers only.
I noticed in Boost.Build there are .jam files and .py files for the utilities, but I didn't see the connection between them?
The .py-s belong to Python port of Boost.Build developed by Volodya, AFAIR https://github.com/boostorg/build/wiki/Python Best regards, -- Mateusz Loskot, http://mateusz.loskot.net