(from-file): Use full file name as search key, to avoid creating two
different targets from two different project, which actually correspond
to the same file.
(register): Use actual name of the target as key. This again avoid
the problem with two equivalent targets in two different projects.
[SVN r23173]
targets to generators, also return them in together which produced targets.
This means that intermediate target will be passed though all target and
eventually end up as dependency of 'all', thereby avoiding the warning
about independent targets.
Besides, the reason why intermediate target were invented still applies:
we want main targets like 'stage' to see all produced targets.
Thanks to Mark Elston for poiting out on the warning.
[SVN r23106]
* tools/common.jam (check-init-parameters): New rule.
* tools/gcc.jam (init): Make use of the above.
* kernel/errors.jam (user-error): New rule.
[SVN r23084]
- Specialized RC->RES generators were added for msvc. This allows
to invoke setup script before calling rc.exe, which adds necessary
include paths.
- Includes scanner for RC files added.
Thanks to Alexey Pakhunov for the patch.
[SVN r23036]
The targets (both abstract and virtual) used to refer to project there belong
to using the name of Jamfile module corresponding to the project. That was a
bit messy, and whatevet it was necessary to get any project attribute, one
had to call 'project.attribute', which was messy too.
Now, projects are identified by instance of project-target class, and
attributes are obtained via 'get' method in that class.
[SVN r23001]
1. Don't break where there are several elements in condition.
2. Don't validate <toolset> feature in condition, since we might
not have initialized all possible toolsets.
[SVN r22964]
'toolset' and 'threading'. The reason is that current link-compatibility
check is way too simple minded and produces bogus warnings. For example,
linking MT library into single threaded application is OK. Likewise, some
toolsets are link-compatible.
We might need a better mechanism, but for now just make the feature
link-compatible. Useless warnings are much worse than failure to report
link-incompatibility in some cases.
[SVN r22949]
we added only dll-path properties and the logic that created dll-path
properties from xdll-path properties did not work right on Windows.
It makes more sense anyway to always add all paths for dendency libraries.
[SVN r22932]
not only on the one we're staging.
On Windows, the action that produces EXE also produces RSP file. If location
of RSP file is not changed when staging, both staged EXE and original EXE will
try to use the same RSP file and that will cause 'duplicate virtual target'
error.
[SVN r22931]
