Re: [boost] [modularization] proposal and poll

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 

 http://www.cmake.org/cmake/help/git-master/manual/cmake-compile-features.7.html 

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

 http://www.kdab.com/modern-cmake-with-qt-and-boost/#compile-feature-specification

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:

 http://www.cmake.org/cmake/help/git-master/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.html

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

 https://gitorious.org/cmake/steveires-cmake/source/0156b7f4:Modules/Compiler/MSVC-CXX-FeatureTests.cmake

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:

 http://www.cmake.org/cmake/help/git-master/module/WriteCompilerDetectionHeader.html

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.

Thanks,

Steve.