Boost logo

Boost :

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 takes me to a page where I
> can download My question was whether it should be a goal
> for it to offer
> Your response was along the lines of 'it doesn't matter to me what the
> download link on 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 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

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

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

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.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at