Re: [Boost-build] Generating CMake package files using Boost.Build

Subject: Re: [Boost-build] Generating CMake package files using Boost.Build
From: Stephen Kelly (hello_at_[hidden])
Date: 2016-05-10 16:06:28

Raffi Enficiaud wrote:

> Hi Steve,
> 
> (I am trying to escape from the main boost.devel ML about this cmake
> topic.)

This refers to:

 http://thread.gmane.org/gmane.comp.lib.boost.devel/266666

and the follow up here:

 http://thread.gmane.org/gmane.comp.lib.boost.devel/266852

Those seem to have run their course now, so time to respond to this.

> I have to say that, even if I am using cmake for more or less 10 years
> now, I do little know about this package producer/consumer feature. I
> guess it is rather "new" (in my time scale).

This is a contradiction to what you wrote here:

 http://thread.gmane.org/gmane.comp.lib.boost.devel/266852/focus=266944

Raffi Enficiaud wrote:
> We have diverging opinions. I am using cmake for more than 10 years now, 
> I do not feel like I am missing some big part of it.

The package config files system is rather a 'big' and 'relevant' part of 
cmake.

> I do believe that what you propose is a good idea. I have some concerns
> though. Please correct me if I am wrong.
> 
> A/ If I understand well, what you propose is for end-users: 

Correct.

> they have
> "something" that allow them to have the binaries on their system
> somewhere, and they can then integrate Boost parts better to their own
> build environment.

Yes.

>    - in what extent would this be better than using the regular CMake
> find(boost) package? This is already doing a good job.

* The config files would be versioned (and likely CI tested) with the boost 
source.
* The config files would be easier to maintain as they are generated from 
canonical information. CMake just makes guesses.
* The FindBoost file needs to be updated with every boost release (see 
_Boost_KNOWN_VERSIONS and the new _DEPENDENCIES variables). That's a burden 
which shouldn't exist at all and wouldn't exist if boost provided config 
files.
* Config package files are the prefered mechanism of the cmake community.

>    - how would you handle dependencies? the question is related on both
> sides: being able to generate the dependencies from boost to cmake
> package, AND being able to tell the consumer about those dependencies.
> How does it work in cmake?

The config files contain IMPORTED targets which depend on each other. See 

 http://www.cmake.org/cmake/help/v3.4/manual/cmake-buildsystem.7.html

and 

 http://www.cmake.org/cmake/help/v3.4/manual/cmake-packages.7.html

Users specify their concrete dependencies and the targets inform CMake about 
their dependencies. CMake computes the rest.

> In your previous example, if we have the dependency "log<-system"

Your arrow (<-) is in the wrong direction. log depends on system. 

You mean:

 log -> system

as in 

 http://www.steveire.com/boost/deps-june-14/log.dot

and

 http://www.steveire.com/boost/deps-june-14/log.png

> , can
> we just have
> 
> """
> find_package(BoostLog REQUIRED)
> """
> 
> and BoosSystem is automatically sourced?

Yes.

> Would that be interesting or
> irrelevant?

Yes. That simplicity is an explicit goal.

> B/ what would be the form of those packages? For Qt for instance, we
> have one big monolithic installation

Qt is modular. Qt ships modular tarballs. Each Qt library installs its own 
CMake config package. There are no dependency cycles between Qt libraries.

It is definitely not monolithic. Certainly on a naive reading of what you 
wrote, it is just wrong.

Boost is not modular. Boost is monolithic. Boost does not ship modular 
tarballs (nor does boost want to do so). There are many dependency cycles 
between Boost libraries.

However, CMake can handle those cycles. I added code to CMake 3.0 
specifically for the boost case.

> , and the consumer chose the
> package. Do you see it like that as well: one big tar containing the
> binaries for a specific platform?

That is up to the Boost community to decide what they want

 http://thread.gmane.org/gmane.comp.lib.boost.devel/254635

Either way, a CMake config package can be created per boost library.

> C/ In case you are distributing the cmake package, how would you
> propagate the toolchain to the consumer, is this handled by CMake? 

The library does not choose the toolchain in CMake. The user chooses the 
toolchain. That's so basic and fundamental to CMake that you must already 
know that, and so clearly I just don't understand your question. Please 
rephrase.

In general, I suggest you look into cmake config packages - try using them 
see what they contain, see what the Qt ones contain, maybe the KDE or 
Grantlee ones.

Thanks,

Steve.