'rank' for each viable generator, we use explicit information of the
form 'generator A is better than generator B', which is provided by
the user. The obvious goal is to fix 'custom_generator' failure on
msvc, but generally, I'm fixing BB76 -- which says that current generators
selection is very broken.
[SVN r25361]
msvc, 0 is returned and that broke the test. But really, we're interested
only if user-defined generator is run, not that the result is compiled.
[SVN r24779]
(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]
'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]
a couple of cases.
1. On Windows, DLLs are never directly linked to, so they are considered
unused and cause a warning. There used to be special code in
exe-target-class and lib-target-class to supress that warning, but this
failed for unit-test, for example, since main target class for unit test
is not related with exe-target-class. And making yet another main target
class looks ugly.
2. A target specified via project-wide <source> or <library> property is
added to sources for all targets, and cause a warning when it's not used.
However, there are valid cases to ignore such sources. For example
obj a : a.cpp : <optimization>off ;
need to comsume any libraries.
It was not clear how to fix both problems. Further, the only case when I found
the warning to be usefull is when declaring new toolsets, and it that case it
does not add much information compared to --debug-generators output. So, let's
just kill the feature for now.
[SVN r22927]
The used 'CALLER_MODULE' to determine the project where the main target
is to be declared, which did not work if the rule is called from another
module.
Thanks to Zbynek Winkler for the bug report.
* build/project.jam (current): New rule
* test/wrapper.py: New test
* other files: Use 'project.current'.
[SVN r22569]
Patch from Andre Hentz.
* v2/build/toolset.jam
(inherit-flags): Take an extra parameter describing properties that
should not be inherited.
* v2/build/type.jam
(register-suffixes): Removed local qualifier.
* v2/test/BoostBuild.py
(prepare_suffix_map): Add .dylib if OS is Darwin.
(Tester::_init_): path to bjam on Darwin.
* v2/test/prebuilt.py
make sure $toolset is expanded correctly.
* v2/test/prebuilt/project-root.jam
use $toolset instead of gcc.
* v2/test/prebuilt/ext/project-root.jam
use $toolset instead of gcc.
* v2/test/prebuilt/ext/Jamfile2.jam
handle extension .dylib.
* v2/test/prebuilt/ext/Jamfile2.jam
handle extension .dylib.
* v2/tools/darwin.jam
inline call to toolset.inherit.
filter <debug-symbols>off because -s is not accepted for dlls.
speficy that .dylib files are of type SHARED_LIB.
(actions link): pass -s for static linkage.
(actions link.dll): pass -L flag with path to libraries.
(actions archive): -c inhibits warning.
[SVN r22332]
