P F wrote:
What I proposed in that thread is for the benefit of boost users and is completely compatible with current boost community values (does not propose moving away from boost.build, which is a too-controversial topic).
Yes, but it seems to be just putting lipstick on a pig.
I definitely don't agree.
Boost should move to being able to be built in a simple and modular way and not require esoteric build tools, which will be a greater benefit to boost users.
Do you have data on how many users care about how boost is built? I'm curious. Which categories of boost users care? If you port a library to cmake, will people using boost from the ubuntu package get the cmake package files? Do you have some kind of plan? Some gradual switch of libraries, of packaging processes and tools and release processes and tools? Some point when building with cmake is the default, then the only way? How long will that take? Because only after that process is completed can a user depend on cmake package files being present, and that's when the boost+cmake *starts* to improve. I really wonder what a viable plan along the lines you are thinking would look like. In my mind, the only way to make the boost+cmake experience better for users in a finite time frame is to generate the package files with boost.build. That way users of package managers will get the cmake files and they will be useful.
Be careful - you're about to get into a discussion of what a dependency is. :)
What I mean by dependency is what is needed to fully build, test, and install the library. I think that is pretty straightforward.
I didn't mean a discussion with me :). I do think there's more relevant nuance to it than that, but let's not bother getting into it. Thanks, Steve.