On Mon, 19 Jun 2017 at 15:39 Stefan Seefeld via Boost
I also want to be able to pick my own build (etc.) tools, not in addition to Boost.Build, but instead of it. I understand that right now that's not supported, which is why I'm writing this proposal. What would it take for Boost to support individual libraries to be built with anything else ? What requirements would that "anything" have to meet, and how would it interact with the existing infrastructure to work ? Is that such a strange request ?
I strongly disagree with allowing that to happen. I'm a fan of the current model of distributing boost because of how I've seen it distributed at large companies. Every company I have worked at has maintained their own custom, internal build system. To integrate boost into any of those systems has been pretty easy -- it involves writing a script to bootstrap, invoke b2, copy headers and libs and possibly generate some synthetic targets to let the custom build system know how to find boost. In some cases I've had to modify boost build to support weird proprietary compiler variants -- which was a pain -- but imagine if every library was doing their own thing? Now in order to use your library, I need to get approval for the licence on the build system, then I need to make the build system work and integrate it with whatever our custom setup is. Then possibly I need to patch it to work with whatever special compiler we're currently using, and I need to potentially do that more than once. For me, the simplicity of monolithic (or at least unified) boost is worth a huge amount and I would really hate to lose that. I feel the same about the licensing issue that came up a few weeks ago for the same reasons -- getting approval to use and distribute boost at a large company is vastly simpler if things are consistent. -- chris