[Boost-build] Problem with Boost Build/Jam recognizing different paths to the same entity as separate targets.

From: Jurko Gospodnetiæ (jurko.gospodnetic_at_[hidden])
Date: 2008-07-04 01:55:47

   Hi.

   This is a split off topic from the '[Accumulators] Problem building 
the combined boost documentation.' thread.

   It was reported that Boost accumulators library documentation fails 
to build due to Boost Build attempting to create some folder twice.

   The following example jamroot.jam file when placed in and used from a 
folder named 'UUU' reproduces an equivallent problem:

> 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 due to
cases 1 & 4 treating paths fff & ../UUU/fff as separate targets. Note 
that in this case repeated builds work fine since Boost Jam detects that 
both targets fff & ../UUU/fff already exist and simply does not trigger 
creating them again.

   Anyone have any thoughts on how to handle such cases?

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

   Should we be prepared to handle stuff like symbolic links?

   Is there any 'standard solution' to such a problem that I am not 
aware of?

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

   Also, on a related but separate topic, 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?

   Best regards,
     Jurko Gospodnetiæ