Re: [Boost-build] [Accumulators] Problem building the combined boost documentation.

From: Jurko Gospodnetić (jurko.gospodnetic_at_[hidden])
Date: 2008-07-03 17:51:28

   Hi Eric.

>>   - When I do a clean build I get an error at some point stating that 
>> the "/cygdrive/c/Documents and 
>> Settings/Jurko/Desktop/Boost_trunk/bin.v2/libs/accumulators" folder 
>> can not be created because it already exists. The error is not 
>> reported in case I simply rerun the build without removing the bin.v2 
>> folder. This might be something akin to your original problem. If so, 
>> then maybe we got lucky and I have something to go on in tracking that 
>> problem down. :-) I may even know where to look for this as I seem to 
>> recall dealing with something similar in the regular Windows bjam 
>> build a few months ago. But I'll have to get back to this later...
> 
> Yes, this sounds like exactly the problem.

   Ok, I managed to reproduce an equivalent problem using regular 
Windows bjam. To reproduce it use the following jamroot.jam file placed 
in a folder called UUU:

> import common ;
> install fff                      : jamroot.jam ; <name>file.1 ;
> install fff/ggg/..               : jamroot.jam : <name>file.2 ;
> install fff/ggg/../ggg/../../fff : jamroot.jam : <name>file.3 ;
> install ../UUU/fff               : jamroot.jam : <name>file.4 ;

   Boost Build tries to battle this problem by normalizing any paths 
passed to it (i.e. shortcircuiting any . path elements except and any .. 
path elements except for the initial series), which makes cases 2 & 3 
above not conflict with case 1. However the path passed in case 4. is 
already normalized and does not get recognized as pointing to the same 
location as the one in case 1. Therefore the initial build fails, while 
any repeated builds work as expected.

   The problem could be solved by updating the bindtarget() function in 
Boost Jam's rules.c source file to find some sort of a 'unique' 
identifier for each of its targets. Any suggestions on what such an 
identifier might be?

   I guess we could attempt to root any non absolute paths from the 
current folder's absolute path and then normalize that. But is that enough?

   Should we be prepared to handle stuff like symbolic links?

   I have not researched this much before, but is there any 'standard 
solution' to such a problem that I am not aware of?

   Is there some portable 'file system object identifier' we can use in 
case the file system already exists? There are some other places in 
Boost Jam code (e.g. file_query() function in filent.c) that could 
benefit from such an identifier since they hash their results based on 
the parameter name and so may cache multiple result sets for the same 
file in some cases. If there is no portable identifier, then are there 
at least different identifiers on different systems?

   Note that this is not just a MkDir problem. Any other target build 
could fail due to similar reasons.

   Best regards,
     Jurko Gospodnetić