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]
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]
