Subject: Re: [Boost-build] Order of include directories in Boost Build
From: Edward Diener (eldiener_at_[hidden])
Date: 2011-02-12 14:56:27
On 2/11/2011 1:09 PM, Steven Watanabe wrote:
> 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
In the order from bottom to top in the list above. The general rule
should be that the closer directory gets included before the farther
directory, and the deeper directory going down gets included before the
less deep. It's not perfect but is surely better than alphabetical order.
> Suppose I have another Jamfile in
> 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.
Big deal. I would rather have better functionality a million times over
than worry about a little extra processing time in my build tools.
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