On 22 May 2014 at 13:44, Stefan Seefeld wrote:
And here we flog that old and very dead horse of C++ package management yet again.
I don't see it being quite dead yet. At least, despite all the flogging, not much has changed, and everyone (in particular package and distribution maintainers) still face the same issues.
There is an argument for making everything, absolutely everything header only in the long run. Modules makes it tractable.
Dave even went off and wrote code to implement a C++ package manager, it's since been abandoned.
I wonder how he thinks of this experience in hindsight, and why he abandoned it.
Around the same time he declared enough of the git migration tool. Enough said.
A more realistic alternative is to let each project come up with their own ways to deal with this, so all users of the project have to care about is precisely the information Tom lists above: what are the (coarse-grained) dependencies, and what are the supported platforms (including compilers) ?
Thing is, BlackBerry initially let each team use whatever tooling it liked for BB10. The result was a disaster, and a huge amount of later work to unify the disparate build systems under a single meta build framework. I think letting people choose their own tooling is disasterous, unless that choice plays nice with any arbitrary other build system. cmake integrates well with any arbitrary build system, it's why I suggested it. bjam isn't terrible, but I have had problems getting it to play nice with surrounding build systems in the past e.g. forcing certain custom compiler toolsets from a surrounding cmake.
Your comments are well intentioned, but C++ package management is very hard, much harder than it looks.
Yeah, but that is no reason to make it even harder by trying to come up with a universal solution that can be imposed on everyone.
Without conformance and imposition there would be no point in joining into the Boost libraries.
We can all wish for dream solutions, but in the end what we must adopt is what is reasonable given people work on this for free during family time.
In that line of thought: I think it's important to reconsider what the value (and thus focus) of Boost is. It's not the tools that are used to build the libraries, it's not the clever hacks that are used to work around compiler deficiencies, it's the new C++ APIs that are developed and made available to the larger C++ development community.
+10
And thus, if someone has great skills in writing (and implementing) such APIs, why should he be forced to learn particular tools to build, test, document, package, etc. his contribution ? Why can't he just pick whatever he is already familiar with, as long as the quality of the outcome meets the expectation ?
+1 in some areas not others, as per my OP. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/