On 2014-05-22 13:07, Niall Douglas wrote:
On 22 May 2014 at 9:23, Tom Kent wrote:
Each library would publish a list of what other libraries it depended on and what compilers (and platforms?) it supported. This would go in a file at the root of its git tree. 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.
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. I already proposed my view of the situation: the problem is that a few people try to solve the problem not for a single project, but for the entire boost community. That community not being very easy, especially when it comes to things related to tools, this was a disaster waiting to happen. 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) ?
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.
A reasonable compromise is probably C++ Modularisation, even that applied to Boost would be a ton of monotonous work people won't be willing to do for free.
We would then provide a tool to the users (like 'b2 headers'/BCP on steroids) that would take a list of libraries that the user wants and the compilers that they want to use. It would then download (or fail the dependency check) these libraries and their dependencies, and build them (or download binaries). This would also work very well with the various linux package managers as they would follow the same dependency pattern with their own tools.
The underlying problem is not a technical one, and I wouldn't expect the solution to be yet another tool.
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. 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 ? Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...