|
Boost-Build : |
Subject: Re: [Boost-build] Order of include directories in Boost Build
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2011-02-11 13:09:48
AMDG
On 2/11/2011 9:42 AM, Edward Diener wrote:
> On 2/11/2011 11:24 AM, Steven Watanabe wrote:
>> On 2/11/2011 8:19 AM, Edward Diener wrote:
>>> On 2/11/2011 11:03 AM, Steven Watanabe wrote:
>>>>
>>>> The thing is that properties in Boost.Build can come
>>>> from quite a few different places. Explicitly specifying
>>>> the places where order matters is safer then letting
>>>> the system automatically guess at what you mean.
>>>> On the other hand, it results in the problems that
>>>> we had here, where the way to fix the problem isn't
>>>> obvious to someone who doesn't know about it already.
>>>
>>> I believe the include directory order should default to directories
>>> which are closer in the directory hierarchy to the directory of the
>>> jamfile coming earlier in the order.
>>
>> Define "closer."
>
> If the jam file is in directory X, a directory at X is closer than one
> anywhere else. A directory one level up from X is closer than a
> directory two levels up from X. etc. etc. etc.
That only covers a few cases.
Given a Jamfile in /home/steven/test,
how should the following directories be ordered
/include/
/include/boost_1_45_0
/home/steven/include
/home/steven/test/include
/home/steven/test/config/include
Suppose I have another Jamfile in
/home/steven/uses-test/
with the same include directories.
Now what should happen?
If the order is different, it will force
the #include scanner to do more work,
if both sets of targets need to be built,
because it won't be able to re-use the
cached dependencies.
> I believe this default
> scheme is much better than the alphabetic ordering currently used for
> the include directories.
>
It will fix this particular case. I'm unconvinced
about how much it will help in general, though.
In Christ,
Steven Watanabe
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk