id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc
2068,Better path comparison for common.mkdir,Eric Niebler,Vladimir Prus,"The problem is exposed by the accumulators doc build, which fails because bjam tries to create the same target directory twice, once with a relative path and once with an absolute path. bjam doesn't normalize the paths correctly and therefore fails to recognize that the targets are the same. The build fails on the second mkdir attempt because the target directory already exists.

Jurko Gospodnetić tracked the problem down to the following:

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. 
",Bugs,new,,build,Boost 1.35.0,Problem,,,