Hi Rene, Robert, all, On 10/12/18 3:04 PM, Rene Rivera via Boost wrote:
With that in mind, what I would like us to do is what I've mentioned many times in the past.. Move towards a truly modular Boost distribution and development that: a) supports users no matter what environment they choose to use Boost Libraries in, b) supports developers to flexibly develop and test their libraries, c) allows Boost to grow in a way that doesn't cripple development resources. This is my goal as well. I believe that a CMake support of boost will take use closer to that goal.
Again, I disagree, no build system will take us closer to that goal because it's not the build system at fault.
+10
I think that without a "fully normalized modular Boost" a CMake, or any other build system, effort is a waste of time. Of course we differ. I don't believe it a grand (intelligent?) design. I believe in evolution. It is my intention that CMake support of boost will bring us close to the goal of a modular boost - which I've referred to in the past as Boost 2.0.
I'm a big fan of incremental progress (which is my attempt at paraphrasing your use of the term "evolution"), and it is precisely for that reason that I think "modularity" must include organizational / administrative aspects (e.g. the ability to take certain decisions per project rather than monolithically for the whole organization) rather than only technical ones (e.g. the ability to build individual projects). Not only would a solution that involves some projects using CMake and some using Boost.Build be a much more convincing demonstration of modularity, it would also address a range of concerns voiced by others (including Edward Diener in https://lists.boost.org/Archives/boost/2018/10/243620.php and myself in https://lists.boost.org/Archives/boost/2018/09/243293.php et al.)
This is a key feature of my proposal and strategy. Other more ambitious and grandiose initiatives have failed in the past because they were too ambitious and grandiose.
This seems to be a question of perspective. To me a proposal to "switch from Boost.Build to CMake for the entirety of Boost" is a way more ambitious goal than to "change the Boost infrastructure to support individual projects to switch to CMake".
This makes it impossible to reach consensus which is the bedrock of Boost.
Consensus would be great, but we (the community) have demonstrated that it has its limits, i.e. it doesn't scale well. And of course, to state the obvious: This isn't a democracy. It's the developers and maintainers who put in the effort to develop and maintain individual projects who should have the ultimate power to decide.
1) Fully normalized library file structure that can be introspected. This would be nice - but I don't think it's essential to making a CMake Boost integration.
True it's not essential. But it would make any build system integration a magnitude easier (and I'm including b2 reintegration here).
"Provide the following integration points: ..." would be a much simpler set of requirements. But I agree of course with the general idea: establish fewer points to be standardized, to improve the ability to encapsulate and insulate "implementation details".
2) Clear inter-library, and non-cyclic, dependency arrangement and information.
+10
3) Abandon the super-project structure as a development and distribution vehicle.
+10
I agree with this. It's my current intention that the "scope and requirements" include the statement like:
"Any CMake support of Boost should not presume any super project or similar directory structure outside of any particular library"
Sounds good.. Just replace "CMake" with "build system".
Yes !! Stefan -- ...ich hab' noch einen Koffer in Berlin...