Cleanup done while researching the Boost Jam internals. Added better implementation description comments at many places. Cleaned up the 'dependant' and 'dependency' terminology that got mixed up in several places. Renamed several functions to use underscores as word separators.
[SVN r48480]
as this option is unknown so the Sun compilers on Linux.
As -xarch=generic is the default on the Sun, there should
be no impact to the Sun platform.
[SVN r48464]
Bug was happening when we had a multifile action that got triggered to build its non-initial target. Then while that action was being executed all the other targets were reporting as 'already built' and were getting used by other actions prematurely. Quick-fixed by making all targets built by a single action list each other as 'included' causing anything else depending on any of these targets to automatically depend on all the others in the group as well.
The solution is not perfect as it might have some unexpected interactions with other uses of 'included' targets and now if any target in a group is not up to date then all of them will be rebuilt even if actually did not need the target that was up to date. On the other hand this should be a really rare use case as it would require the one target in a group to be up to date and be needed while another in the same group (i.e. built by the same action) to not be up to date.
[SVN r48426]
vfork() on the Mac. This works around known issues
with bjam on PPC under Tiger and a problem reported
by Rene with bjam on x86 under Leopard.
A future revision will change execvp() use to execve()
to enable the Mac to once again use the more efficient
vfork() on the Mac.
[SVN r45956]
As it was written before the rule had 'random' behavior in some borderline cases such as: not passing it a parameter, passing it a folder whose path starts with one or two backslashes (as opposed to slashes) or passing it an invalid rooted path with enough '..' path elements to take it 'before the root path'. In those cases it would cause an access violation, 'incorrectly' un-root the path (i.e. remove the leading slash) or simply remove a 'random' path modification respectively. Also the rule is now more tiny bit more efficient and much better documented.
Invalid rooted paths with enough '..' path elements to take them 'before the root path' are now recognized and an empty list is returned.
Due to this rule having such 'messy' behavior the path.join rule and its user make-NT rule had some twisted logic in them to work around all the problems this caused. This patch invalidates the logic in question and replaces it with a much simpler one (detailed comments added).
Other NORMALIZE_PATH callers should not be affected since both the old and the new version work the same on 'regular' paths (i.e. those not mentioned above).
The new functionality for recognizing Boost Jam versions has been used to make Boost Build scripts use the old path functionality when using Boost Jam older than 3.1.17 and use the new functionality otherwise. As consequence, now anyone using the trunk version of Boost Build and an older 3.1.17 version of Boost.Jam will need to recompile their Boost Jam executable.
The patch does not cause any Boost Build or Boost Jam tests to fail.
Added a related NORMALIZE_PATH Boost Jam test. Note that this test causes Boost Jam versions built prior to this patch to crash (access violation).
Added additional internal Boost Build tests for the path.jam module testing how it handles some invalid Windows paths.
[SVN r45158]
When scanning directories and creating a list of all their content (filent.c) it would identify all the located files and folders using their long file names. On the other hand, referencing a target using its short file name inside a Jam script caused Boost Jam to reference those files twice using two separate TARGET structures - one identified using the file's short name and one using the file's long name.
One bad example was the MkDir which would always attempt to create a folder identified by its short name even if that folder already existed (due to the NOUPDATE rule getting applied on the incorrect TARGET).
The change does not affect targets whose names do not represent existing file names.
Also, it seems to me that the short_path_to_long_path() call in file_dirscan() in the filent.c module should most likely be moved to file_info() in the filesys.c module. This would make mapping file names to file_info_t & TARGET structures consistent. However, I have not done this in this patch just to make the patch as minimal as possible.
Prepared tests have been do nothing on non Windows platforms.
[SVN r45144]
This was caused by the file_dirscan() function in the filent.c module not working correctly when passed '\' as its dir. It then messed up when formatting its file-selection parameter for the _findfirst()/findfirst() API and constructed it as '\/*' which caused that API to fail and return -1 which was in turn being interpreted as 'file not found'.
[SVN r44088]
Solved the problem with bjam going into an active wait state, hogging up processor resources, when waiting for one of its child processes to terminate while not all of its available child process slots are being used. To see this bug in action, try compiling a simple C++ program on a 2 processor PC with the -j 2 command-line option and watching how much processor resources bjam uses while linking. Was caused by treating unused process slots as used in the try_wait() function, causing the WaitForMultipleObjects() Windows API call to exit instantly with an error which was then getting incorrectly interpreted as a timeout, starting the whole cycle anew.
Solved a race condition between bjam's output reading/child process termination detection and the child process's output generation/termination which could have caused bjam not to collect the terminated process's final output.
Extracted all GetExitCodeProcess() API calls into one location so it no longer gets called in three separate places.
Minor comment changes in code touched by previous fixes.
[SVN r44087]
