Re: [boost] Boost header isolation testing

Subject: Re: [boost] Boost header isolation testing
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2018-10-16 16:44:36

On Tue, 16 Oct 2018 at 13:41, James E. King III via Boost
<boost_at_[hidden]> wrote:
> On Tue, Oct 16, 2018 at 4:41 AM Andrey Semashev via Boost <boost_at_[hidden]> 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
> > > <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.
> >
> >
> 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