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/