Re: [boost] Thoughts on Boost v2

Subject: Re: [boost] Thoughts on Boost v2
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-05-22 17:27:48

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/