Re: [boost] [cmake] Pull request announcement

On Sat, Sep 15, 2018 at 11:33 AM mike via Boost wrote:

...

-----Original Message----- From: Boost On Behalf Of Bjorn Reese via Boost Sent: Saturday, September 15, 2018 2:11 PM To: Mike Dev via Boost Cc: Bjorn Reese Subject: Re: [boost] [cmake] Pull request announcement

On 09/14/18 13:44, Mike Dev via Boost wrote:

...

This will not address - Testing [...] In short: all the difficult stuff is left out ;) The goal is not to present a solution that can replace b2 but to have a minimal starting point upon which individual library authors or the community as a whole can make iterative improvements. If and when BCM (or an alternative) is accepted into boost, individual libraries can then easily switch to this full-fledged solution and of course any author can create a more complete CMake solution for his library at any time (as some already have).

In my experience, we want to have both an integration and standalone CMake file. This split is necessary to avoid problems with multiple instances of enable_testing() when using one library from another.

* The integration file builds only what is necessary for integration into other projects. This is similar to what you are proposing.

* The standalone file builds everything including test and documentation. This reuses the integration file to build the library itself.

If we place your proposed CMake file in the library root, and dependent libraries start using that location, then it becomes difficult to later have the standalone CMake file in the library root, which is the more natural choice. So we should be cautious about where we place these files.

Could you elaborate, why this would require separate/conflicting cmake files as opposed to having multiple different targets in a single file?

More to the point: Anything related to testing should reside in a cmake file inside the "tests" folder, which is called from the cmake file at the root, but that is mainly a matter of properly structuring the cmake code - just as you usually don't put all your code into a single header file, even if it might end up in a single translation unit in the end. The same is true for docs.

In particular: Just because a cmake file is processed doesn't mean any of the targets it contains have to be build automatically.

If you have genuine concerns however, I'm happy to further discuss them in detail. I certainly don't want to do anything that will prevent a future full-fledged cmake version.

I have used CMake for about 10 years now on pretty large projects, and I have never seen a need to have different CMakeLists files for different purposes. If you want to provide a build option where tests are not built or executed, you would add a top level option (throwing in examples and docs too): OPTION(BOOST_DOCS "Build documentation." OFF) # most people won't have the required tooling OPTION(BOOST_EXAMPLES "Build examples." ON) OPTION(BOOST_TESTS "Build the tests." ON) Unlike b2, tests do not typically run as part of a build when you use cmake. There are three phases of a cmake based build (well, four really...) 1. Create an out-of-tree build directory and generate the build environment with cmake. 2. Build using the generated build environment (which can be invoked with "cmake --build .") 3. Run tests using ctest. (4. cpack to build packages) If you were to perform step 1 (generating the build) with "cmake -DBOOST_TESTS=OFF" then step 3 would either do nothing or produce an error indicating tests were disabled. Someone asked what the naming convention for the libraries should be. You can teach CMake how to name libraries; the naming convention can be identical to how b2 does it. I don't see why it has to be any different than b2. CMake isn't without it's oddities either. Selecting the build architecture and type (debug, x64) is done in step 1 on unix, but it is done on step 2 on windows. CMake does not natively provide windows package management. In all of the CMake build systems I have used or created so far I have always had to make an environmental harness to deal with third party deps. If anyone has tried to build libicu on windows (as an example), you know what a pain this can be. Therefore for it to be successful, tight integration with a package manager that supports Windows would be ideal - something that can provide libicu and the other boost dependencies automatically. I believe for example conan has some cmake integration. Finally, someone suggested the project maintain both build systems long term. That would be a mistake. I've seen what this can do in other projects (like Apache Thrift, which uses autoconf for a complete linux build, and cmake for windows which is only a subset of languages). Each check-in would need to prove it builds correctly in two very different build systems. It is a lot to ask of folks submitting changes, but obviously the "complete" build environment has to work until the new one becomes "complete" and replaces it. - Jim