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]
* Jamroot: use symlink, not hardlink
* tools/build/v2/tools/symlink.jam: Implement fallback
for doing symlinks on Windows.
Fixes#1902. Thanks to Frank Mori Hess for the patch.
[SVN r45445]
generate.
We try to avoid building the same target twice, by caching the result of
previous calls to target.generate, and returning it if a build request
with the same property set is made. When the target fails to generate,
for example due to <build>no property, we used to store the entire
build property set as the usage requirements of the build. This is clearly,
wrong, this patch makes us store <build>no as usage requirements instead.
Fixes#1816.
[SVN r45245]
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]
Among other things this was breaking the new Boost Jam version detection functionality in some realistic cases. Added related regression tests.
[SVN r45100]
