Change 4397
This is in reference to email from Daniel Weber
<DaWeber@harmanbecker.com> on the Jamming mailing list.
The problem as posed is essentially that the SUBDIR_TOKENS are not
set correctly when you SubInclude a Jamfile whose SubDir is not
a direct child of of the SubIncluding Jamfile, and whose TOP is
not the same as the including Jamfile.
The result of his fix is that the SUBDIR_TOKENS, etc are set as
relative to the including Jamfile's root when jam is called from
the including tree, and as relative to its own TOP when jam is
called from within the sub tree in which the included Jamfile
resides.
I'm not sure if this is correct behavior - my initial response is
that I would expect the SUBDIR_TOKENS, etc. to be relative to the
TOP most recently set by a call to SubDir. This seems like the
most straightforward and modular possibility - a given Jam project
would have the same behavior regardless of whether it is being
compiled on its own or as a sub-part of a larger project.
Nevertheless, the behavior Mr. Weber describes is clearly wrong
so I'm integrating his fix.
See change 4396 for a related test bed.
<DaWeber@harmanbecker.com> on the Jamming mailing list.
The problem as posed is essentially that the SUBDIR_TOKENS are not
set correctly when you SubInclude a Jamfile whose SubDir is not
a direct child of of the SubIncluding Jamfile, and whose TOP is
not the same as the including Jamfile.
The result of his fix is that the SUBDIR_TOKENS, etc are set as
relative to the including Jamfile's root when jam is called from
the including tree, and as relative to its own TOP when jam is
called from within the sub tree in which the included Jamfile
resides.
I'm not sure if this is correct behavior - my initial response is
that I would expect the SUBDIR_TOKENS, etc. to be relative to the
TOP most recently set by a call to SubDir. This seems like the
most straightforward and modular possibility - a given Jam project
would have the same behavior regardless of whether it is being
compiled on its own or as a sub-part of a larger project.
Nevertheless, the behavior Mr. Weber describes is clearly wrong
so I'm integrating his fix.
See change 4396 for a related test bed.