Re: [boost] Proposal for moving Boost to CMake

Subject: Re: [boost] Proposal for moving Boost to CMake
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2017-06-18 19:47:35

Le 18.06.17 à 21:05, Louis Dionne via Boost a écrit :
> Boost - Dev mailing list wrote
>> Howdy all,
>>
>> This is a request for comments on a possible path for migrating Boost's
>> build system to CMake.  [...]
>
> FWIW, I support this (or something very similar). Reading some of the
> discussions in this thread, it seems like people are getting caught into the
> trap of discussing the specifics of how we would implement a proper
> CMakeLists.txt file and so on. I think this is completely missing the point.
> What we need is to acknowledge that the current situation of supporting
> Boost.Build only is a major pain for our users since they (1) most likely
> don't use it in house, (2) don't know it, (3) don't want to learn it, and
> (4) have to deal with it whether they like it or not. If you go into the
> wild, you'll find
> - people that don't use Boost because it's too hard to build or integrate
> into their build system
> - people that only use the header-only libraries because they don't have to
> build them and/or because the integration is as simple as changing a header
> path
> - people that build properly but are tired of maintaining their bridge
> between Boost.Build and their own system
>
> This, I think is our real problem. The discussion is not about whether it's
> better for Boost library developers to use Boost.Build, CMake, or Bazel for
> that matter. It's about what's best our users, who GREATLY outnumber us. And
> given that CMake is the de-facto standard, the best way to help our users is
> to provide easy integration of Boost with that build system (however that
> happens).
>
> It is also worth noting that people on this list that oppose vocally are
> Boost library developers or folks with deep involvement/knowledge of
> Boost.Build, which is a very small minority. This has become clear through
> years of anecdotal evidence (such as speaking to people at conferences).
> Based on this and previous failed attempts, I think it is unlikely that
> we'll be able to make a decision based solely on discussion on this list,
> and my opinion is that a top-down decision is required to make something
> (anything) happen, like for the Git modularization.
>
> That being said, I would like to propose an alternative route that is softer
> than David's to see what people think. I still think that David's proposal
> is better, but if that was uncontroversial enough, perhaps this could get
> the ball rolling and we could go from there (and provide some relief to our
> users in the meantime).
>
> The proposal is to add to the Boost library guidelines the requirement that
> a XYZConfig.cmake module be provided with the installation of any Boost.XYZ
> library. This module would simply export the proper CMake targets, which
> would solve the problem of integrating Boost with a CMake-based build system
> and would remove the need for the custom FindBoost support in CMake. This
> would not make Boost easier to build, but once built and installed, it would
> at least be trivial to use _properly_ from a CMake project. This does not
> require changing the build system of existing libraries to CMake.
>
> Regards,
> Louis

I am totally for a better support of CMake, and what you suggest is ok 
to me. However (and since the topic is already very huge), maybe I 
missed some elements. This is usually what I do:

1. I build boost using bjam and install it in some folder
2. in "my_other_project" that uses cmake, I just specify 
-DBOOST_ROOT=/myboostinstallfolder and everything works like a charm.

This is something I always did and it always worked, I do not see any 
strong limitation on it. So when you say "properly", does it mean the 
support the user gets in case of failure? or for maintaining his own 
configuration for having FindBoost running ok?

Does this means that, all the problems we are facing and trying to solve 
in this thread are due to the proper integration of some static or 
shared libraries installed in some path, and users not being able to 
import those in their own cmake project? (because FindBoost does an ok 
job, as does FindGoogleTest, FindCUDA, etc etc).

Thanks,
Raffi