Subject: [Boost-bugs] [Boost C++ Libraries] #2068: [jam] path normalization is broken
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2008-07-03 22:10:50
#2068: [jam] path normalization is broken
--------------------------+-------------------------------------------------
Reporter: eric_niebler | Owner: jurko
Type: Bugs | Status: new
Milestone: Boost 1.36.0 | Component: bjam
Version: Boost 1.35.0 | Severity: Showstopper
Keywords: |
--------------------------+-------------------------------------------------
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.
-- Ticket URL: <http://svn.boost.org/trac/boost/ticket/2068> Boost C++ Libraries <http://www.boost.org/> Boost provides free peer-reviewed portable C++ source libraries.
This archive was generated by hypermail 2.1.7 : 2017-02-16 18:49:58 UTC