Re: [boost] [modularization] proposal and poll

Nat Goodspeed wrote:

On Fri, May 30, 2014 at 8:31 AM, Peter Dimov 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.h... 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-specific... 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... 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... 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/WriteCompilerDetectionHead... 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.