Re: [boost] [CMake] what to do now?

On Apr 13, 2016, at 6:55 PM, Stephen Kelly wrote:

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 the users wants the latest boost(as system level package managers are usually behind) or the user is cross-compiling. Where I used to work, we always built boost because of cross-compiling. This usually required translating the cmake toolchain to the boost toolchain. Using cmake all the way through would make that easier.

If you port a library to cmake, will people using boost from the ubuntu package get the cmake package files?

I don’t know the details with that because I usually always use pkg-config over the cmake package files. I would assume so, since pkg-config files are available from ubuntu packages(not boost packages but other packages provide them).

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 see it happening on a per-library basis at first rather than as whole which is much more complicated. So, say we get rid of our cycles in Boost.Core and Boost.Config, then we can have libraries such as Boost.PP, Boost.Predef, Boost.Config, Boost.Core, and Boost.Hana building with cmake. Then libraries that depend on those can start to move to use cmake as well. A tool then can be used to retrieve and build the library and its dependencies(using rypple or cget). So then when the user wants Boost.Filesystem it can download and build the libraries needed just for Boost.Filesystem. Eventually the release process would move to a per-library release such as Boost.Filesystem 2.0 and then Boost.Filesystem 3.0 rather than everything versioned by the boost monolithic release. Then libraries that fail to move forward due to lack of maintainers or refusal to deal with cycles would then be left behind.

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.

It would make the experience better in the short-term.

...

...

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.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost