Re: [Boost-build] [Boost-commit] svn:boost r75765 - trunk/tools/build/v2/engine

Subject: Re: [Boost-build] [Boost-commit] svn:boost r75765 - trunk/tools/build/v2/engine
From: Vladimir Prus (ghost_at_[hidden])
Date: 2011-12-02 07:08:43

On 02/12/11 08:48, Steven Watanabe wrote:
> AMDG
>
> On 12/01/2011 01:45 PM, Vladimir Prus wrote:
>> On 01/12/11 23:34, steven_at_[hidden] wrote:
>>>
>>>    OBJECT * short_path_to_long_path( OBJECT * short_path )
>>>    {
>>> <snip>
>>
>> Should we even be calling this on gristed paths?
>>
>
> After some thought I've concluded that bindtarget
> should not call short_path_to_long_path ever.
>
> Rationale:
>
> a) Removing the call doesn't affect building Boost.
> b) short_path_to_long path only works for files
>     that exist.  Thus, if a target is generated,
>     short_path_to_long_path causes inconsistent
>     behavior depending on whether the file already
>     exists or not.  In the worst case we can have
>     a bizarre situation like:
>
> # file.jam
> var = global ;
> var on target = target ;
> ECHO [ on Target return $(var) ] ;
> actions build
> {
>      echo string>  $(<)
> }
> build target ;
> UPDATE target ;
>
> $ b2 -d0 -f file.jam
> global
> $ b2 -d0 -f file.jam
> target

This is surely ugly behaviour.

> c) short_path_to_long_path only works for targets
>     that are bound relative to the current working
>     directory or use an absolute path.  If SEARCH
>     or LOCATE is set, it makes no sense.
>
> If we're going to call short_path_to_long_path
> at all, it should probably be in search, since
> that's where targets are bound to physical
> file system locations.

It appears like the original problem that caused addition of short_path_to_long path,
namely that user or environment can specify some paths using either short paths or
using different capitalization, is still there. So, I am not sure how we can get
along without normalization somewhere. and bindtarget seems like the only place where
we can reasonable normalize target names. Say, if Boost.Build action produces parser.h
and .cpp includes "Parser.h", this is something that should work, but it's only at
engine target level, bindtarget in particular, that we can handle it. Or there are
other approaches?

Thanks,
Volodya