On Jul 28, 2017, at 7:25 PM, Rene Rivera via Boost <boost@lists.boost.org> wrote:

On Fri, Jul 28, 2017 at 7:03 PM, paul via Boost <boost@lists.boost.org> wrote:

...

Hi,

So, I have made a small demo setting up the tests with cmake, here:

https://github.com/pfultz2/boost-cmake-demo/tree/bcm-test-demo

This builds and tests the libraries for Boost.System, so it includes:

The predef script is incorrect. This < https://github.com/pfultz2/boost-cmake-demo/blob/bcm-test-demo/libs/predef/test/CMakeLists.txt#L25> is not equivalent to the original < https://github.com/pfultz2/boost-cmake-demo/blob/bcm-test-demo/libs/predef/test/build.jam#L60>. As the "-DCHECK_VALUE=true" is not passed to compiler in response to the evaluation of '"BOOST_COMP_CLANG > 0.0.0" "BOOST_OS_LINUX == 0"'. It needs to try to compile and run one of the programs from here < https://github.com/pfultz2/boost-cmake-demo/tree/bcm-test-demo/libs/predef/tools/check>. The test is verifying that both this < https://github.com/pfultz2/boost-cmake-demo/blob/bcm-test-demo/libs/predef/tools/check/predef.jam> and this < https://github.com/pfultz2/boost-cmake-demo/blob/bcm-test-demo/libs/predef/tools/check/predef_check.h> work as expected. For cmake you would need still need to test the latter, still.

Yes, I need to add a custom function `predef_check` in cmake to support this, although it would be best to do the detection directly in cmake rather than through the running the tool, but either way I need to build these tools in cmake as well. Thanks for the feedback.

Louis Dionne wrote:

If we go Paul's way (which is IMHO the right way in the long term), ...

I've given it some thought and I like the BCM approach; BCM should be a library in libs/bcm (if we retain the name). But I think that Paul's insistence to support the cget workflow, for which nobody at the moment cares but him, is making things more complicated and error-prone than they could be. (The cget workflow is the ability to build and install Boost libraries one by one, independently of one another, without a superproject; this requires them to refer to one another with find_package.)

P F wrote:

Either way, several authors has expressed their desire to have their libraries built standalone, which means they would need to use `find_package` to get their dependencies.

That's their choice and their problem. Does not follow that everyone else needs to do it too.

I think the error-prone is coming from repeating the dependencies twice.

Error-prone comes from find_package in boost_foo finding the system package boost_bar because you haven't installed the libraries in the correct order. Although I suppose this could be prevented by using EXACT.

On 7/29/2017 5:02 AM, Peter Dimov via Boost wrote:

Louis Dionne wrote:

...

If we go Paul's way (which is IMHO the right way in the long term), ...

I've given it some thought and I like the BCM approach; BCM should be a library in libs/bcm (if we retain the name).

Perhaps a tool in tools/bcm ?

But I think that Paul's insistence to support the cget workflow, for which nobody at the moment cares but him, is making things more complicated and error-prone than they could be. (The cget workflow is the ability to build and install Boost libraries one by one, independently of one another, without a superproject; this requires them to refer to one another with find_package.)

On 7/29/2017 10:50 AM, Peter Dimov via Boost wrote:

Edward Diener wrote:

...

On 7/29/2017 5:02 AM, Peter Dimov via Boost wrote:

...

...

I've given it some thought and I like the BCM approach; BCM should be a > library in libs/bcm (if we retain the name).

Perhaps a tool in tools/bcm ?

One could argue for that, if we go by principle alone.

Pragmatically speaking, I prefer being able to submodule boostorg/foo and boostorg/bcm side by side and then have `include(../bcm/bcm_deploy)` in foo/CMakeLists.txt, instead of having to submodule foo as libs/foo and bcm as tools/bcm and then have `include(../../tools/bcm/bcm_deploy)` in foo/CMakeLists.txt.

Understood, but bcm is really a tool to work with Boost libraries rather than what is ordinarily thought off as a Boost library itself. What will end-users think if we mix tools and libs in the same hierarchy <g> ?

Peter Dimov wrote:

But I think that Paul's insistence to support the cget workflow, for which nobody at the moment cares but him,

Agree, I personally don't care about cget (sorry Paul). I think it's a neat tool, but I'm not using and I don't think we should predicate any technical decision on the ease of interoperation with cget. HOWEVER...

is making things more complicated and error-prone than they could be.

I don't think that's the case, see below.

(The cget workflow is the ability to build and install Boost libraries one by one, independently of one another, without a superproject; this requires them to refer to one another with find_package.)

This is not specific to the cget workflow. Generally speaking, if we want to be able to consider libraries as individual entities (or "packages"), the recommended way of resolving dependencies is to use `find_package`. This is really neat, as it means we could e.g. ship individual libraries using Conan. That's the big modularization that some of us have been talking about (and many users want) just at our fingertips, and we only need to use `find_package` instead of leaving the dependencies be implicit. Louis -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-tests-with-cmake-tp4697568p4697605.... Sent from the Boost - Dev mailing list archive at Nabble.com.

Edward Diener wrote:

I do not understand two issues:

1) Why does find_package have to be used for header-only libraries at all ? Or what does it buy you in CMake terms for header-only libraries?

I'm assuming you're referring to using find_package as opposed to just saying `-I path-to-library/include`. Header-only libraries have requirements just like built libraries. For example, a header-only library could require you to use -std=c++14, or to link with some non-header-only library when you depend on it. By properly declaring your header-only library and its requirements (in terms of dependencies, compiler options, macro definitions, whatever), and by using find_package + target_link_libraries, you inherit the requirements of the header-only library.

2) Why is it assumed that individual Boost libraries can be shipped when there is no current or proposed version control to insure that some individual Boost library shipped by itself will actually work properly with some other individual Boost library shipped by itself that is its dependent ?

That's a thornier question, actually. What Hana does is simply that it tests itself against all Boost versions up to the current trunk. I don't think we want this as a blanket policy, however.

Is there an encompassing solution in CMake to this problem?

When/if we decide on a compatibility policy across different libraries, I think we may be able to use `find_package` with custom version compatibility checking to implement it. All that being said, I'm not saying we should try to make all Boost libraries usable individually as part of the CMake effort. We should not. However, I think any solution that makes this impossible is unacceptable, both because it bars us from doing it in the future and because some libraries (such as Hana) require it today. Louis -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-tests-with-cmake-tp4697568p4697609.... Sent from the Boost - Dev mailing list archive at Nabble.com.

On Sun, Jul 30, 2017 at 1:59 PM, Louis Dionne via Boost <boost@.boost> wrote:

...

All that being said, I'm not saying we should try to make all Boost libraries usable individually as part of the CMake effort. We should not. However, I think any solution that makes this impossible is unacceptable, both because it bars us from doing it in the future and because some libraries (such as Hana) require it today.

Currently there is no requirement that some or all Boost libraries are "usable individually."

* What is the definition of "usable individually?"

Outside of the superproject. The definition I'm using is that the following workflow should work: .. install prerequisites for some-library into some ${PREFIX} .. git clone some-library cd some-library mkdir build cd build cmake .. -DCMAKE_PREFIX_PATH=${PREFIX} cmake --build . # The library builds and uses the dependencies installed at the # specified location. These dependencies can be set up manually # or using a real package manager (Conan, cget, whatever).

* It seems we have added a stealth requirement. Cmake integration is not enough now?

Please read my message again. I said we should NOT tackle this as part of the CMake effort. I just said that any solution that makes this impossible is bonkers (IMO) since it (1) is already required by some libraries that ship individually (2) goes against the best practices for CMake such as in [1] (3) would prevent us from having a truly modular Boost in the future Also, doing this properly only requires saying `find_package` for the dependencies that a library has, which we could argue is good even if only as a documentation of the "cost" of a library. I really don't see how `find_package` makes anything more difficult, as it's a no-op for superproject builds anyway. Louis [1]: https://youtu.be/bsXLMQ6WgIk?t=55m48s -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-tests-with-cmake-tp4697568p4697615.... Sent from the Boost - Dev mailing list archive at Nabble.com.

On Jul 29, 2017, at 3:09 AM, Louis Dionne via Boost <boost@lists.boost.org> wrote:

Boost - Dev mailing list wrote

...

Hi,

So, I have made a small demo setting up the tests with cmake, here:

https://github.com/pfultz2/boost-cmake-demo/tree/bcm-test-demo

This builds and tests the libraries for Boost.System, so it includes:

* assert * config * core * predef * static_assert * system * winapi

There are no tests for winapi right now, because I don't have a windows machine to test on(but I suppose I could've tested with mingw).

This uses the BCM modules to provide common functionality for building and tests. All the tests are setup to run through CTest, and some targets are provided for building the tests.

A `tests` target will build(but not run) all the tests. The `check` target will build and run all tests.

Since we do want to filter tests by library, all tests are added with the label of the project name(which can be filtered with `ctest -L <label> `). Furthermore there are targets `tests- <project-name> ` and `check- <project- name> ` that will build and test a single project respectively. So if we are only interested in the tests for `boost_assert` we can run:

cmake --build . --target check-boost_assert

And this will build and test `boost_assert`.

Any feedback will be useful as we move forward on adding the rest of the tests to cmake.

Paul

I think this is absolutely incredible. I may not agree with every last detail about how BCM handles things, but my opinion is that this is the way we should go. Based on your example and the dependency report, I think it should be easy to do MPL + Fusion (I can have a shot at those). I'll also give a shot at making Hana use the same conventions you do with BCM and I'll be able to provide some feedback based on actual experience.

Sure. The next step is try to integrate this into the scripting I have to generate the cmake. This way we can create a full build with the tests working. Also, we need to figure out how to approach Boost.Config’s require rule it adds with cmake. It probably just be config check, and the user can write their own conditional in cmake. There is a few changes I made to the testing in this example so it works on the small subset(config and core depend on type traits), but for the full build these changes won’t be necessary.