https://svn.boost.org/trac10/ticket/2068 <p> 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. </p> <p> Jurko Gospodnetić tracked the problem down to the following: </p> <p> 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: </p> <pre class="wiki">import common ; install fff : jamroot.jam ; &lt;name&gt;file.1 ; install fff/ggg/.. : jamroot.jam : &lt;name&gt;file.2 ; install fff/ggg/../ggg/../../fff : jamroot.jam : &lt;name&gt;file.3 ; install ../UUU/fff : jamroot.jam : &lt;name&gt;file.4 ; </pre><p> 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 &amp; 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. </p> <p> 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? </p> <p> 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? </p> <p> Should we be prepared to handle stuff like symbolic links? </p> <p> I have not researched this much before, but is there any 'standard solution' to such a problem that I am not aware of? </p> <p> 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? </p> <p> Note that this is not just a <a class="missing wiki">MkDir</a> problem. Any other target build could fail due to similar reasons. </p> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/2068 Trac 1.4.3 Jurko Gospodnetic Mon, 07 Jul 2008 10:32:20 GMT https://svn.boost.org/trac10/ticket/2068 https://svn.boost.org/trac10/ticket/2068 <ul> <li><strong>attachment</strong> → <span class="trac-field-new">common.jam.patch</span> </li> </ul> <p> Suggested patch for working around problems detected with the Boost Accumulators library documentation build. </p> Ticket Jurko Gospodnetic Mon, 07 Jul 2008 10:34:32 GMT https://svn.boost.org/trac10/ticket/2068#comment:2 https://svn.boost.org/trac10/ticket/2068#comment:2 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">assigned</span> </li> </ul> Ticket Jurko Gospodnetic Wed, 09 Jul 2008 08:18:30 GMT https://svn.boost.org/trac10/ticket/2068#comment:3 https://svn.boost.org/trac10/ticket/2068#comment:3 <ul> <li><strong>summary</strong> <span class="trac-field-old">[jam] path normalization is broken</span> → <span class="trac-field-new">Suggested quick-fix patch applied applied to the trunk.</span> </li> <li><strong>severity</strong> <span class="trac-field-old">Showstopper</span> → <span class="trac-field-new">Problem</span> </li> <li><strong>milestone</strong> <span class="trac-field-old">Boost 1.36.0</span> → <span class="trac-field-new">Boost 1.37.0</span> </li> </ul> <blockquote> <p> Suggested quick-fix patch committed to the Boost trunk. </p> </blockquote> <blockquote> <p> Changeset link: <a class="ext-link" href="http://svn.boost.org/trac/boost/changeset/47260"><span class="icon">​</span>http://svn.boost.org/trac/boost/changeset/47260</a> </p> </blockquote> <blockquote> <p> This makes the problem no longer a showstopper for the Boost 1.36 release. </p> </blockquote> Ticket Vladimir Prus Fri, 29 May 2009 09:00:30 GMT https://svn.boost.org/trac10/ticket/2068#comment:4 https://svn.boost.org/trac10/ticket/2068#comment:4 <ul> <li><strong>summary</strong> <span class="trac-field-old">Suggested quick-fix patch applied applied to the trunk.</span> → <span class="trac-field-new">Better path comparison for common.mkdir</span> </li> </ul> Ticket Vladimir Prus Tue, 10 Nov 2009 07:12:51 GMT https://svn.boost.org/trac10/ticket/2068#comment:5 https://svn.boost.org/trac10/ticket/2068#comment:5 <ul> <li><strong>owner</strong> changed from <span class="trac-author">Jurko Gospodnetic</span> to <span class="trac-author">Vladimir Prus</span> </li> <li><strong>status</strong> <span class="trac-field-old">assigned</span> → <span class="trac-field-new">new</span> </li> </ul> Ticket Vladimir Prus Sun, 10 Jan 2010 10:14:47 GMT https://svn.boost.org/trac10/ticket/2068#comment:6 https://svn.boost.org/trac10/ticket/2068#comment:6 <ul> <li><strong>component</strong> <span class="trac-field-old">bjam</span> → <span class="trac-field-new">build</span> </li> <li><strong>milestone</strong> <span class="trac-field-deleted">Boost 1.37.0</span> </li> </ul> Ticket