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]
requires both the parent and child process to explicitly set
the process group id. Vfork guarantees the child process
runs to the exec before it releases the parent process.
Now that we use fork instead of vfork, it's possible for the
parent to wait on the child process without having the child
setpgid on itself. This eliminates spurious hangs on ppc
darwin caused by either a race condition between vfork and
execvp, or a bug in the vfork implementation.
Added a test to ensure we don't try to read from the
stderr pipe descriptor if the descriptor's not valid.
[SVN r43176]
Consequences & checks:
* Final __ACTION_RULE__ rule parameter has changed from output ? to output-lines *.
* Updated corresponding Jam documentation.
* Updated the all related Boost Build code.
* No code on the Boost trunk uses this rule except for Boost Build itself.
[SVN r42629]
* Reflect added start/end timestamps for actions in xml output. And update action rules for new args.
execcmd.h
* Add start/end timestamps to action timing info.
execnt.c
* Fix filetime_seconds calculation when time is larger than low 32 bit value.
* Add calc of C time_t from Windows FILETIME.
* Add start/end timestamps recording to action timing info.
execunix.c
* Add start/end timestamps recording to action timing info.
jam.c
* Change JAMDATE to use common ISO date format.
make1.c
* Redo __TIMING_RULE__ and __ACTION__RULE__ invocations to new argument ordering and added end/result timestamp values.
[SVN r41431]
