|
Boost : |
Subject: Re: [boost] Some statistics about the C++ 11/14 mandatory Boost libraries
From: Thijs (M.A.) van den Berg (thijs_at_[hidden])
Date: 2015-05-13 15:46:37
> On 13 May 2015, at 20:36, Stefan Seefeld <stefan_at_[hidden]> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk