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:
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
On Sun, 4 Aug 2013, at 12:27 PM, Stephen Kelly wrote: 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.