18 Jun
2017
18 Jun
'17
9:20 p.m.
> On Jun 18, 2017, at 3:03 PM, Edward Diener via Boost <boost@lists.boost.org> wrote: > > On 6/18/2017 3:05 PM, Louis Dionne via Boost wrote: >> 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. > > Please give a specific example of what this XYZConfig.cmake module entails ? For a header-only library ? For a built library ? For running tests ? For creating documentation ? Along with some sort of decent explanation of what is going on in each situation. I think Daniel Pfeifer “Effective CMake” talk gives a good overview how this can be done in cmake. Of course, doing this outside of cmake would be a little more work, but probably could be built-in to boost build(which can handle the heavy lifting).