On 19.06.2017 10:59, Peter Dimov via Boost wrote:
Stefan Seefeld wrote:
I have no idea why you are mentioning all this. How often do I need to repeat that this proposal is about modularization, not about decoupling the release process of individual Boost components ?
All right. What, specifically, do you want further modularized? Did you even read what I wrote in my other posts?
I did, yes. Sorry for not specifically acknowledging that. I know about these tricks (I use something similar to set up my Boost.Python CI environment), but consider them hacks as they don't really solve the fundamental requests, which are: * I want to be able to build a given Boost library stand-alone, with nothing but the library's repo being checked out. (In other words: prerequisite Boost components should be assumed pre-installed.) * I want to be able to choose the build (, test, etc.) infrastructure used for my library, and make sure that when Boost is built as a whole, that build infrastructure is used. I can't stress this enough: this second point is to 99% non-technical. It's about letting project maintainers decide how they develop (build, test, etc.) so we don't have to have these "lets all switch from tool A to tool B" discussions any longer. The choice between b2, cmake, scons should be done per project, rather than the whole Boost organization at once. The only technical aspect of this is the definition of the interface between super-project and sub-project, i.e. the mechanism by which Boost.Build invokes the library-specific build systems for those of us who want to continue building Boost as a whole. Stefan -- ...ich hab' noch einen Koffer in Berlin...