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.
