Re: [boost] Thoughts on Boost v2

Subject: Re: [boost] Thoughts on Boost v2
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2014-05-22 13:44:29

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...