|
|
Boost-Build : |
From: Jurko (jurko_jamboost_at_[hidden])
Date: 2003-08-30 14:37:16
The bug probably manifests itself only on machines using Windows
OS and only if you set the root of the unpacked boost-build tarball to
be the root of a disk, as for example when using 'subst m: boost-build'
as I did while testing so that all the displayed paths would be shorter
and thus more readable.
Here is a description of steps that can be taken in order to reproduce
this bug.
1. Unpack the Milestone 6 tarball and go to its root (boost-build folder).
If needed, comment out the 'broken' lines in user-config.jam file, but
that has nothing to do with this bug except enabling bjam to work at
all.
2. In that folder run the command 'subst m: .' .
3. Go to disk m:. Now your current path should look like 'M:\' .
4. To witness the modules missing from the list just do 'bjam --help-all'.
You should see only three modules listed:
* build-system: This file is part of Boost.Build version 2.
* errors:
* modules:
and after they are displayed there should be a longish pause until
all the other header scans have finished.
I think this bug points out several deficiencies in the code:
1. The handling of the the DOS/Windows root folder should be fixed.
* PWD built-in rule returns a path that ends in a slash (e.g. M:\)
if bjam was called from the root folder. In any other folder that
path does not end in a slash.
* $(filename:D) for a file that's located in the root folder again
returns a path that ends in a slash while for any other folder it
does not.
* When $(filename:R=$(folder)) is used to prefix a folder to the
given filename, and that filename does not start with eather
forward of backward slash, in which case the folder is not
prefixed at all, then they are always separated by a slash.
I guess that would be forward slash on UNIX and a backslash
on Windows, but here I only saw backslash being used. This
can result in multiple slashes when the folder itself ends in
a slash, e.g. if it's the root folder. My suggestion is to change
this so that the slash is not added if the folder itself already
ends in one. That is one of the things that could stop the
bug described in this post as the multiple slashes are
confusing the algorithms in other parts of the code (but that's
not the only thing that should be fixed - see below).
To see an example of multiple slashes call bjam from the
root folder and then look at the value of BOOST_BUILD_PATH
variable after it's first set in Jambase or appended with more
paths in kernel/bootstrap.jam.
2. Two different sorting algorithms are being used in two different
places to do the same thing.
* One is the sequence.insertion-sort algorithm used in the
process rule in options/help.jam to sort all the found modules to
be scanned.
* The other is the sorting algorithm most probably implemented
inside Boost.Jam used to determine the actual order in which
scheduled header scans are done.
They must be different (or more precisely must be sorting
different strings) because the code uses the first algorithm to
decide which .jam file is scanned last but the second algorithm
doesn't put that file in the last position so then the rule
print-help-all is called to soon before all the files have been
scanned. That's why there is a delay after the results are
printed out - the system is still scanning the files missing from
the list. :-)
3. The code in options/help.jam is trying to write out the output after
the last .jam file has been scanned by trying to 'guess' (and in this
case failing to guess correctly) which file will be scanned last and
scheduling the output after that precise file has been scanned. I
guess a better way to do this would be to schedule the output after
all the files have been scanned, but I do not know if Boost.Jam has
a hook that can bee used for such scheduling. If it doesn't, then
perhaps it should be added.
Hope this helps whomever is maintaining this help system code.
The self-generating help system itself fascinated me. :-) Excellent
work!
Best regards,
Jurko
---------------------------------
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software --0-2136928725-1062272236=:60419 Content-Type: text/html; charset=us-ascii
<DIV>
<DIV> Ok, here's some more info on that help system bug.</DIV>
<DIV> </DIV>
<DIV> The bug probably manifests itself only on machines using Windows</DIV>
<DIV>OS and only if you set the root of the unpacked boost-build tarball to</DIV>
<DIV>be the root of a disk, as for example when using 'subst m: boost-build'</DIV>
<DIV>as I did while testing so that all the displayed paths would be shorter</DIV>
<DIV>and thus more readable.</DIV>
<DIV> </DIV>
<DIV>
<DIV> Here is a description of steps that can be taken in order to reproduce</DIV>
<DIV>this bug.</DIV></DIV>
<DIV> </DIV>
<DIV>1. Unpack the Milestone 6 tarball and go to its root (boost-build folder).</DIV>
<DIV>If needed, comment out the 'broken' lines in user-config.jam file, but</DIV>
<DIV>that has nothing to do with this bug except enabling bjam to work at</DIV>
<DIV>all.</DIV>
<DIV> </DIV>
<DIV>2. In that folder run the command 'subst m: .' .</DIV>
<DIV> </DIV>
<DIV>3. Go to disk m:. Now your current path should look like 'M:\' .</DIV>
<DIV> </DIV>
<DIV>4. To witness the modules missing from the list just do 'bjam --help-all'.</DIV>
<DIV>You should see only three modules listed:</DIV>
<DIV> * build-system: This file is part of Boost.Build version 2.<BR> * errors:<BR> * modules:</DIV>
<DIV>and after they are displayed there should be a longish pause until</DIV>
<DIV>all the other header scans have finished.</DIV>
<DIV> </DIV>
<DIV>
<DIV> I think this bug points out several deficiencies in the code:</DIV></DIV>
<DIV> </DIV>
<DIV>1. The handling of the the DOS/Windows root folder should be fixed.</DIV>
<DIV> </DIV>
<DIV> * PWD built-in rule returns a path that ends in a slash (e.g. M:\)</DIV>
<DIV> if bjam was called from the root folder. In any other folder that</DIV>
<DIV> path does not end in a slash.</DIV>
<DIV> * $(filename:D) for a file that's located in the root folder again</DIV>
<DIV> returns a path that ends in a slash while for any other folder it</DIV>
<DIV> does not.</DIV>
<DIV> * When $(filename:R=$(folder)) is used to prefix a folder to the</DIV>
<DIV> given filename, and that filename does not start with eather</DIV>
<DIV> forward of backward slash, in which case the folder is not</DIV>
<DIV> prefixed at all, then they are always separated by a slash.</DIV>
<DIV> I guess that would be forward slash on UNIX and a backslash</DIV>
<DIV> on Windows, but here I only saw backslash being used. This</DIV>
<DIV> can result in multiple slashes when the folder itself ends in</DIV>
<DIV> a slash, e.g. if it's the root folder. My suggestion is to change</DIV>
<DIV> this so that the slash is not added if the folder itself already</DIV>
<DIV> ends in one. That is one of the things that could stop the</DIV>
<DIV> bug described in this post as the multiple slashes are</DIV>
<DIV> confusing the algorithms in other parts of the code (but that's</DIV>
<DIV> not the only thing that should be fixed - see below).</DIV>
<DIV> </DIV>
<DIV> To see an example of multiple slashes call bjam from the</DIV>
<DIV> root folder and then look at the value of BOOST_BUILD_PATH</DIV>
<DIV> variable after it's first set in Jambase or appended with more</DIV>
<DIV> paths in kernel/bootstrap.jam.</DIV>
<DIV> </DIV>
<DIV>2. Two different sorting algorithms are being used in two different</DIV>
<DIV>places to do the same thing.</DIV>
<DIV> </DIV>
<DIV> * One is the sequence.insertion-sort algorithm used in the</DIV>
<DIV> process rule in options/help.jam to sort all the found modules to</DIV>
<DIV> be scanned.</DIV>
<DIV> * The other is the sorting algorithm most probably implemented</DIV>
<DIV> inside Boost.Jam used to determine the actual order in which</DIV>
<DIV> scheduled header scans are done.</DIV>
<DIV> </DIV>
<DIV> They must be different (or more precisely must be sorting</DIV>
<DIV> different strings) because the code uses the first algorithm to</DIV>
<DIV> decide which .jam file is scanned last but the second algorithm</DIV>
<DIV> doesn't put that file in the last position so then the rule</DIV>
<DIV> print-help-all is called to soon before all the files have been</DIV>
<DIV> scanned. That's why there is a delay after the results are</DIV>
<DIV> printed out - the system is still scanning the files missing from</DIV>
<DIV> the list. :-)</DIV>
<DIV> </DIV>
<DIV>3. The code in options/help.jam is trying to write out the output after</DIV>
<DIV>the last .jam file has been scanned by trying to 'guess' (and in this</DIV>
<DIV>case failing to guess correctly) which file will be scanned last and</DIV>
<DIV>scheduling the output after that precise file has been scanned. I</DIV>
<DIV>guess a better way to do this would be to schedule the output after</DIV>
<DIV>all the files have been scanned, but I do not know if Boost.Jam has</DIV>
<DIV>a hook that can bee used for such scheduling. If it doesn't, then</DIV>
<DIV>perhaps it should be added.</DIV>
<DIV> </DIV>
<DIV>
<DIV> Hope this helps whomever is maintaining this help system code.</DIV>
<DIV>The self-generating help system itself fascinated me. :-) Excellent</DIV>
<DIV>work!</DIV>
<DIV> </DIV>
<DIV> Best regards,</DIV>
<DIV> Jurko</DIV>
<DIV> </DIV></DIV></DIV><p><hr SIZE=1>
Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/evt=10469/*http://sitebuilder.yahoo.com">Yahoo! SiteBuilder</a> - Free, easy-to-use web site design software --0-2136928725-1062272236=:60419--
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk