On 10/11/18 9:45 PM, Rene Rivera via Boost wrote:
Second, I think the scope and goals of supporting CMake, even though well intentioned, fall short of what Boost needs to do to resolve the varied afflictions that plague us.
Well, the scope, goals and requirements of CMake as it relates to Boost aren't decided yet. That is the current discussion. I don't believe that CMake will address all the afflictions that plague us. I believe it will make boost in someway better. That is my aspiration.
In what follows when I refer to: "users" I mean those programmers that obtain Boost and use the libraries in their projects, and "authors" as the programmers that develop and support the Boost Libraries and tools.
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.
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.
As it doesn't address the long term viability of Boost.
Not explicitly. But I believe it will contribute to the long term visibility of Boost.
And hence if we are going to spend considerable effort it should be towards modularity.
By keeping the scope relatively narrow, I hope to be able to make actual progress. 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 makes it impossible to reach consensus which is the bedrock of Boost. We've tried the marxist approach to move to Boost 2.0 and it's failed us. Now we're going to try capitalism - which accepts and embraces failure is an inevitable cost of moving forward.
In addition to the standard requirements that Robert mentioned here's what I think is required for a modular Boost:
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.
2) Clear inter-library, and non-cyclic, dependency arrangement and information.
LOL - the hole grail! It's never going to happen. The advocates of this view have totally misunderstood the meaning and role of dependency in this context. Like the knights of old, they will continue to pursue this holy grail - always getting closer - but never capturing the prize. I've recently described my views on this in detail (for the Nth time!) on slack in a thread with Peter Dimov. And for the Nth time I've failed to convince anyone! LOL If he's sir galahad, maybe I'm don quijote - both pure of heart but totally misguided in different ways. (I'm just being entertaining here - I know I'm right and have proven it many times.)
3) Abandon the super-project structure as a development and distribution vehicle.
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"
To telegraph my intent for when it's time for proposals.. I think that for #1 above I think we should be forward looking and follow the Pitchfork structure proposal <http://bit.ly/2Edy4pC>.
Interesting - but as I said before - out of scope.
As for build system.. I think I only have one additional requirement given the above:
1) We should support generating multiple build system files for distribution and development from the introspection of the modular Boost libraries to support the varied user and developer needs.
LOL - that could mean anything - maybe you should run for office! I think I get the idea but would phrase it differently: "A CMake integration should not conflict with the current build system or other boost tools" Robert Ramey