Boost logo

Boost-Build :

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ć

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at