Re: [Boost-build] Cache-file path handling bug on Windows

Subject: Re: [Boost-build] Cache-file path handling bug on Windows
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2013-05-16 12:18:13

AMDG

On 05/16/2013 08:23 AM, Jurko Gospodnetić wrote:
>   Hi all.
> 
>   I encountered a slight problem when using the latest Boost Build HEAD
> on Windows.
> 
>   Not really sure what the project-cache.jam file created in the build
> folder is, but I found a use case when creating it on Windows fails due
> to a badly constructed file name.
> 
>   To reproduce do the following:
>     1. Prepare an empty project folder.
>     2. Add a jamroot.jam file containing just 'project XXX ;'.
>     3. Open a command-prompt in that project folder.
>     4. Run bjam with the following parameter:
>         '"--build-dir=%CD%\xxx"'.
> 
>   This will cause output like:
> 
>> C:\Users\Jurko\ggg>bjam.exe "--build-dir=%CD%\xxx"
>> ...found 1 target...
>> ...updating 1 target...
>> config-cache.write /C:/Users/Jurko/ggg/xxx/XXX/project-cache.jam
>> The filename, directory name, or volume label syntax is incorrect.
>>
>>     type "C:\Users\Jurko\AppData\Local\Temp\jam15e4f4de.000" >
>> "/C:/Users/Jurko/ggg/xxx/XXX/project-cache.jam"
>>
>> ...failed config-cache.write
>> /C:/Users/Jurko/ggg/xxx/XXX/project-cache.jam...
>> ...failed updating 1 target...
>> ...found 1 target...
> 
>   The issue itself is not really important and does not have any serious
> repercussions on my projects. I just thought it would be better for
> Boost Build if such an ugly error message did not pop up.
> 
>   Problem seems to be caused by the jam target's path being constructed
> with an additional leading slash separator, i.e. using internal Boost
> Build instead of native OS path representation.
> 
>   The problem can be patched by tweaking the save() rule in
> config-cache.jam a bit. Instead of:
>     local target = <new-cache-file>$(.cache-file) ;
> do:
>     local cache-file-native = [ path.native $(.cache-file) ] ;
>     local target = <new-cache-file>$(cache-file-native) ;
> 

This looks correct.  Please commit it.

>   However, from my quick-glance through the code, I am not really sure
> this is a clean solution. I do not understand why the <new-cache-file>
> prefix is used nor did I check to see if other Boost Jam targets in
> Boost Build are constructed using their full path information or not.
> 

The grist is to distinguish between different
targets with the same name.  The target used
to read the cache needs to be different from
the target used to write the cache.

>   Could someone more familiar with this code (Steven?) take a look? Or
> should I go and dig deeper?
> 
>   Also, some test for this project-cache.py functionality should be
> added to the Boost Build test suite. I can add it if someone can explain
> to be what it is supposed to do.
> 

It affects any tests using configure.  The
sole effect is to avoid rerunning configuration
tests.

In Christ,
Steven Watanabe