- XSL stylesheet parameter boost.doxygen.reftitle sets the title of the
generated library-reference element.
build/v2/tools/doxygen.jam:
- Free feature "reftitle" sets the title of the generated library-reference
element.
[SVN r23332]
The order is preserved by making properties of the form
<find-static-library>lib1&&lib2&&lib3 and then adding "lib1", "lib2",
"lib3" in the right order.
[SVN r23251]
together.
* tools/rc.jam: Move a lot of staff from tools/msvc.jam
* tools/msvc.jam: Change RC->OBJ generator into RC->RES and add
optional property for this generator, so that it's not used on
other toolsets.
* build/generators.jam
(generator.__init__, register-standard): Accept 'optional-properties'
parameter.
[SVN r23247]
* 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]
'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]
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]
