On Tue, 18 Jul 2017 at 15:00 Louis Dionne via Boost
(1) Users have a hard time integrating Boost into their build system, which is CMake more often than not (but not always, and we're trying to please the majority here)
(2) Prospective Boost developpers are sometimes driven away from submitting because they would have to use Boost's build system, which they don't know.
Furthermore, there was an implicit understanding that if the community as a whole objected to any change or could not come to any consensus, nothing would be forced onto it. However, the _intent_ is clear, and it is that if we do have a good solution for solving problems (1) and (2), we should do it (as opposed to rejecting it, like what has happened in the past).
I would love to see the Boost community come together and figure out how we can solve problems (1) and (2) in the best possible way.
Louis
It has been discussed multiple times that supporting (1) does not require switching to CMake. (2) probably does, but from my point of view, that would actually make boost less usable in my work environment. I use CMake for all of my personal and open source projects and it's great for that, but no company I have worked for has used CMake internally for anything. I'm sure that there are companies that do, but in my experience, every big C++ shop maintains their own custom build system so switching to CMake will add a new dependency that didn't previously exist. It's probably not a deal breaker, but it is a regression because every time I upgrade boost, I might need to upgrade CMake, and because we don't rely on system installed packages for anything I would need to upgrade CMake in our internal package manager before I can upgrade boost. Currently, all I need to do it write a script called from our custom build system that does something like; - call bootstrap - call b2 with appropriate flags (this is the hard part) - add the include path - synthesize the link libraries What's nice about this is that there are no dependencies -- everything is completely self contained, and I like that. For me, from a user point of view, I like things they way they currently are. I can build boost easily in a work environment with no dependencies when not using CMake. When I am using CMake, I can easily set BOOST_ROOT and call FindPackage(Boost) and everything just works. I've had very few problems with this. I've never had to deal with boost.build in any significant way, so I can't speak to how difficult it is. But I feel like this keeps coming up because some people really don't like boost.build and are tying to force the change and something the users really want when that's not actually the case when considering the wider audience. -- chris