Boost logo

Boost :

Subject: Re: [boost] [cmake] Pull request announcement
From: Cem Bassoy (cem.bassoy_at_[hidden])
Date: 2018-09-16 12:21:07


Could perhaps some of the more experienced developers provide sth like a
pro and con list comparing cmake and the boost.build system?
(maybe also including the coverage of test and documentation?) or also
examples where we can see the benefit in terms of simplicity, maintainence,
user experience :-), etc.

I think some contributors/maintainers (including myself) are not able to
appreciate (lack of experience/knowledge) the advantage of cmake over the
boost.build system. For some the 'real' benefits might not be as clear as
for the experienced users of build systems.

Best
C

Am So., 16. Sep. 2018 um 13:47 Uhr schrieb James E. King III via Boost <
boost_at_[hidden]>:

> 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
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk