Re: [Boost-build] Order of include directories in Boost Build

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:
> 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

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
> /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.

Big deal. I would rather have better functionality a million times over 
than worry about a little extra processing time in my build tools.