Boost header isolation testing

older
Boost CMake support - Request for...

James E. King III

15 Oct 2018 15 Oct '18

6 p.m.

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). I pulled this into uuid when I started maintaining it, and I find myself pulling it into another repository. It would be nice to have this as a standard Boost.Build rule that one could easily add to test Jamfiles. Is there anything like this that exists right now in Boost.Build? - Jim

Show replies by date

Steven Watanabe

15 Oct 15 Oct

6:24 p.m.

AMDG On 10/15/2018 12:00 PM, 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). I pulled this into uuid when I started maintaining it, and I find myself pulling it into another repository. It would be nice to have this as a standard Boost.Build rule that one could easily add to test Jamfiles. Is there anything like this that exists right now in Boost.Build?

Making a generalized version of this is a bit tricky as there are a lot of things that can vary and I'm not really sure how to parameterize it in a sane way. The most annoying part of the code is calculating the name of the target, and unfortunately, this is also the part that is most likely to need customization. In Christ, Steven Watanabe

Mateusz Loskot

7:11 p.m.

On Mon, 15 Oct 2018 at 20:00, 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). I pulled this into uuid when I started maintaining it, and I find myself pulling it into another repository.

I've done similar for GIL: https://github.com/boostorg/gil/pull/147

...

It would be nice to have this as a standard Boost.Build rule that one could easily add to test Jamfiles.

Yes, it would be nice to have a rule that takes list of header files, and calculates targets one per header. I stole the target name calculation idea from Log or Test https://github.com/boostorg/log/blob/develop/test/Jamfile.v2 https://github.com/boostorg/test/blob/develop/test/Jamfile.v2 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

Roger Leigh

7:43 p.m.

On 15/10/18 20:11, Mateusz Loskot via Boost wrote:

...

On Mon, 15 Oct 2018 at 20:00, 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). I pulled this into uuid when I started maintaining it, and I find myself pulling it into another repository.

I've done similar for GIL: https://github.com/boostorg/gil/pull/147

...
It would be nice to have this as a standard Boost.Build rule that one could easily add to test Jamfiles.

Note for the CMake side this is pretty simple to automate here. An example would be these functions: https://gitlab.com/rleigh/ome-files-cpp/blob/master/cmake/HeaderTest.cmake which are used here https://gitlab.com/rleigh/ome-files-cpp/blob/master/cmake/HeaderTest.cmake https://gitlab.com/rleigh/ome-files-cpp/blob/master/test/ome-files/CMakeList... to generate a list of headers to test and then to build and run the tests. This tests both inclusion and double-inclusion to check for ODR violations and problems with include guards. The above were created for a specific project and aren't generic, but an equivalent could easily be written for Boost. Regards, Roger

Mateusz Loskot

8:18 p.m.

On Mon, 15 Oct 2018 at 21:43, Roger Leigh via Boost wrote:

...

On 15/10/18 20:11, Mateusz Loskot via Boost wrote:

...
On Mon, 15 Oct 2018 at 20:00, 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). I pulled this into uuid when I started maintaining it, and I find myself pulling it into another repository.

I've done similar for GIL: https://github.com/boostorg/gil/pull/147

...
It would be nice to have this as a standard Boost.Build rule that one could easily add to test Jamfiles.

Note for the CMake side this is pretty simple to automate here.

Thanks, but Boost.Build does the job for GIL very well, and in simple manner as well. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net p.s. Let's leave CMake discussions for CMake threads, please

Vinnie Falco

16 Oct 16 Oct

1:14 a.m.

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. Regards

Andrey Semashev

8:41 a.m.

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.

James E. King III

11:40 a.m.

On Tue, Oct 16, 2018 at 4:41 AM Andrey Semashev via Boost < boost@lists.boost.org> 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. Still needs a little more work to be generic, and as was stated may not suit all cases, but I suspect it will suit most. I noticed in Boost.Build there are .jam files and .py files for the utilities, but I didn't see the connection between them? - Jim

Mateusz Loskot

4:44 p.m.

On Tue, 16 Oct 2018 at 13:41, James E. King III via Boost wrote:

...

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

Vinnie Falco

10:02 p.m.

On Tue, Oct 16, 2018 at 1:41 AM Andrey Semashev via Boost wrote:

...

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

Well that is precisely my point. Speaking only to the problem of checking if public headers compile on their own, a solution which does not require cooperation from the build script brings us one small step towards that goal which has been discussed heavily but without significant progress: Boost libraries which may be individually packaged without the need to come with the entirety of Boost. There have also been CMake noises. Relying on the Jamfile to check if public headers compile on their own only means that such functionality will need to be re-implemented for other build tools. Regards

2233

Age (days ago)

2234

Last active (days ago)

List overview

Download

9 comments

6 participants

participants (6)

Andrey Semashev
James E. King III
Mateusz Loskot
Roger Leigh
Steven Watanabe
Vinnie Falco