On 13 May 2015, at 20:36, Stefan Seefeld
wrote: On 13/05/15 02:10 PM, Niall Douglas wrote: If Boost decides on a future build system solution, we can do better than that.
Right. But again, much as you said earlier, this needs to be a help to boost library authors, not liability. In other words, boost library authors should have the freedom to pick the tools of their choice to develop (including build and package) their respective libraries.
And thus, in that new world, "if boost decides" wouldn't be valid, because each boot library project has to decide for itself.
I think this is important. If I build software that depends of other software then I adapt to the package management tools that are available because those have a lot of benefits for me: stability and easy deployment. They also have very little burden, eg I have to maintain a text file with one line for each dependency -including version constraints-. The benefits for me and the low cost of implementing it makes it a tool I choose to use. I think a automated dependency check/enforcing via git is a monolithic solution, but I might be wrong -maybe that's more about integration testing, validation of dependencies-, but is that something that needs to be done in a central place? I like something like pythons virtualenv, -or node package manager-, where you pin and install specific versions of libraries for specific projects/builds. For me a central repository of libraries with versions would be very useful, together with simple tools that download and install version X of libraries into some local project directory instead of system-wide, and automatically build binaries if needed. I also agree with Nial about using intermediate consensus as a stepping stone to some goal one possibly can't reach today.