Re: [boost] [cmake] Pull request announcement

Subject: Re: [boost] [cmake] Pull request announcement
From: James E. King III (jking_at_[hidden])
Date: 2018-09-16 11:46:45

On Sat, Sep 15, 2018 at 11:33 AM mike via Boost <boost_at_[hidden]>
wrote:

> > -----Original Message-----
> > From: Boost <boost-bounces_at_[hidden]> On Behalf Of Bjorn Reese
> via Boost
> > Sent: Saturday, September 15, 2018 2:11 PM
> > To: Mike Dev via Boost <boost_at_[hidden]>
> > Cc: Bjorn Reese <breese_at_[hidden]>
> > 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