Re: [boost] [modularization] Are modular releases a goal or a non-goal?

Subject: Re: [boost] [modularization] Are modular releases a goal or a non-goal?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-09-18 05:14:52

On 18 Sep 2014 at 11:01, Stephen Kelly wrote:

> >> But, I guess you're saying 'for me it's a non-goal'.
> > 
> > No,
> 
> Let me rephrase. The download link on boost.org takes me to a page where I 
> can download all-of-boost.zip. My question was whether it should be a goal 
> for it to offer boost-static_assert.zip. 
> 
> Your response was along the lines of 'it doesn't matter to me what the 
> download link on boost.org does. Here is my solution...', or with a 
> different paraphrase 'what you describe is not a goal for me. My goal 
> is...'.
> 
> Or you're saying you want the download link on boost.org to point to your 
> tool?

Oh now I see what you're saying. You're saying that the git submodule 
boost.thread should be separately downloadable as boost-thread.zip 
right?

What I was very badly explaining was that can't be useful until each 
submodule is capable of standing alone - or, at the very minimum, 
each submodule indicates which other submodules it depends on, and 
significant effort is invested in tidying up the sloppy inadvertent 
dependencies which are in there. But then you especially know all 
this already.

I then outlined how I am going about breaking off the libraries I 
listed so they can work without the rest of Boost by using the C++ 11 
STL instead. They could be very easily distributed as standalone zip 
archives, indeed I was going to get github to do that for me.

> > and the lack of decisive leadership on this issue merely delays the
> > inevitable to the detriment of all.
> 
> A lack of leadership or cohesion on this issue is indeed disappointing.

I have personally recently invested some time into creating a 
donations channel for Boost, so lack of funding at least will not be 
an issue. I have also invested some time into arranging for GSoC 
students to stay on after GSoC at Boost expense to work on Boost, so 
by next year hopefully lack of grunt workers will also not be an 
issue.

> > So I'm pressing ahead with my own solution - I specifically want
> > single git submodule dependencies, so when I throw together a Boost
> > using project I merely need to submodule a single Boost git submodule
> > and it just works with no arsing around with bootstrapping or config
> > or staging.
> 
> And the user will be responsible for adding the individual -Ifoo/include 
> paths?

I won't be supporting non-header-only libraries, so no linking needed 
apart from system libraries, and yes you're on your own for those. 
This only really affects GCC anyway, clang and MSVC auto-link system 
libraries.

Include paths are straightforward. My tool replicates the boost 
header structure into a faked boost/* directory include structure, so 
you simply use a different -Ipath and you're good to go.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/