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