Re: [boost] Removing old config macro and increasing compiler requirements.

Subject: Re: [boost] Removing old config macro and increasing compiler requirements.
From: Stephen Kelly (steveire_at_[hidden])
Date: 2013-08-04 07:14:59

On 08/04/2013 01:08 PM, Daniel James wrote:
> On Sun, 4 Aug 2013, at 12:56 PM, Stephen Kelly wrote:
>> On 08/04/2013 12:45 PM, Daniel James wrote:
>>> On Sun, 4 Aug 2013, at 12:27 PM, Stephen Kelly wrote:
>>>> Note that the libraries are all in an interdependent mesh. So attempting
>>>> to use any one of them (not just the 'any' one of them :) ) results in
>>>> requiring all of them.
>>>>
>>>>  http://thread.gmane.org/gmane.comp.programming.tools.ryppl.devel/9/focus=26
>>> I tried deleting the unordered library from my repo and could still run
>>> the any tests just fine. So unordered's compiler requirements don't
>>> affect boost::any's at all, even though it's in your list. Module
>>> dependencies are too coarse grained. They pull in a lot of transitive
>>> dependencies that don't affect actual use. Which is what determines
>>> compiler requirements.
>> That's not unexpected. I expect you did not use an old enough/platform
>> specific enough compiler to require all the conditional dependencies.
>> For example, if you used GCC3.3+ boost::config does not depend on
>> boost::core for you.
> But in terms of the compile, I believe config only depends on
> "boost/type.hpp" and "boost/non_type.hpp" from core, which both depend
> on nothing. 

Correct. But they are in the boost::core library along with other files
which do have dependencies. Therefore as boost::config depends on
boost::core for only those two files, boost::config gets all the
dependencies of boost::core transitively. I'm actually even a bit
confused by what you wrote because I thought this would be very obvious.
Did I misunderstand what you wrote?

Please see also what I wrote before about moving those files being a
potential solution in this particular instance, but that increasing the
compiler requirement is the better solution because it enables further
modularization:

 http://thread.gmane.org/gmane.comp.programming.tools.ryppl.devel/201

> So all the dependents pulled in by a modularization system
> do not affect the compiler requirements at all.

I'm sorry, I don't understand what you're saying here.

Thanks,

Steve.