Re: [boost] Boost header isolation testing

Subject: Re: [boost] Boost header isolation testing
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2018-10-16 08:41:07

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
> <boost_at_[hidden]> 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/ec1c8ada7a22b274cf6e58c019c2bbe6965f6232/test/beast/core/file.cpp>
> 
> 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.