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]
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]
<toolset-msvc:version>7.1 <toolset>msvc
we used to get error if default value of <toolset-msvc:version> is 6.0.
* build/feature.jam
(expand-subfeatures-aux): Do no apply subfeature defaults, since it causes
the above troubles and is also performed in 'add-defaults'.
[SVN r22607]
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]
* Moved XML sources to src
* Added reference.css from Reece Dunn to html dir
* Added images from boost/doc/html so that local builds look ok
[SVN r22175]
