Boost logo

Boost :

Subject: Re: [boost] [modularization] proposal and poll
From: Stephen Kelly (hello_at_[hidden])
Date: 2014-05-30 09:45:14

Nat Goodspeed wrote:

> On Fri, May 30, 2014 at 8:31 AM, Peter Dimov <lists_at_[hidden]> wrote:
>> Glen Fernandes wrote:
>>> It would be nice if both approaches (static configuration, automatic
>>> identification) take into account - or allow you to specify -
>>> conditional dependencies (e.g. dependencies based on identification of
>>> supported or unsupported features determined by Boost.Config).
>> It would be nice, but is it implementable? How could the dependency
>> tracker determine what Boost.Config will define?
> I've been assuming that Julian's proposal will require, at least
> initially, that someone (the library maintainer, an interested
> volunteer) manually edit a specification in some syntax of the other
> libraries on which this one directly depends. That information could
> be informed by, but need not be identical to, the output of a tool.
> In that case, Glen's suggestion only requires that the specification
> syntax include some way of annotating each dependency: "only for the
> following toolsets..."
> It may also be possible to write a (wave-based?) tool that analyzes
> the preprocessor conditions under which each #include is reached, but
> I see that as very much a separable (and deferrable) effort.

The initial topic of this thread was 'Does Boost have modularization as a
goal'. There seems to have been topic-creep. Nevertheless, I suggest you and
anyone else interested read

which I implemented, and which allows transitive propagation of compile
feature requirements at a buildsystem level.

Especially if you think 'Does this library use C++11' and 'Does this library
use C++14' are good questions, you should reconsider and re-frame your
question in terms of what features are required from the compiler instead.
Especially consider that in the light of what Robert Ramey wrote about 4
variants of C++. There are not 4 variants. There are many more than 4. There
are as many variants as there are versions of compilers you support, which
each support different features.

No MSVC release 'supports C++11' (or C++98, if you want to be very
pedantic), but it does support some features described in it which other
compilers also support. That is what is relevant, not the C++ standard

CMake is aware of all C++11 and C++14 features and can depend on a target or
not depending on whether the compiler in use supports a particular feature
or features:

though someone would have to contribute and maintain a listing for MSVC
supported features something like:

Even if you don't rely on CMake, you should consider a similar design with
b2 or any new tool you create. Trying to keep the information in
Boost.Config and extract it for use by the buildsystem or dependency
resolver would be awkward.

You can move the information about what compiler has what feature into b2
and use that information to generate Boost.Config, as CMake does:

HOWEVER: All of this is off-topic for this thread. I'm listing it only
because people are thinking too far down the line and getting stuck. I
recommend dropping discussion of tooling and how to record/resolve
dependencies. Understand that there are solutions for what will come up down
the line and you don't need to worry about them now.

I recommend you return to the question of whether Boost wants to modularize
or not.

If you do want that, then consider whether my recommendations linked in the
start of the thread are specific or concrete. There were suggestions in this
thread that my recommendations were not concrete or specific or didn't show
any benefit.

I don't understand or agree with those conclusions, but I think those are
the useful and small questions you guys should focus on if you want to make
any conclusive progress at all on this issue.



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