(load-parent): New rule, extracted from 'initilize'.
(load-jamfile): If loading project-root.jam, check for
Jamfile and load it in the same module.
(inherit-attributes): Simplify.
(project-rules.constant, project-rules.path-constant): New rules.
* build/targets.jam
(project-target.__init__): New paramater 'parent'.
(project-target.inherit)
(project-target.add-constant)
(project-target.intern-constants): New rules
*
[SVN r26251]
* build/project.jam
(project-context.use-project): Just record parameters, don't do anything.
(load): After Jamfile is loaded, use data recorded above to load
additional projects.
* test/test_all.py: New test.
[SVN r26229]
* build/toolset.jam (inherit-generator): New parameter 'generators-to-ignore'.
* tools/gcc.jam: Ignore *link* generators when inheriting. Declare the
gcc specific generator.
* test/gcc_runtime.py: Test that <link-runtime>static is correctly handled.
The gcc specific generator is necessary exactly for that reason.
[SVN r25700]
(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]
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]
* tools/builtin.jam
(linking-generator): Move <library> properties to sources in the 'run'
method. This makes the logic usable by everyone who invokes the generator.
(exe-target-class, lib-target-class): Don't do the above.
[SVN r20707]
* build/targets.jam
(basic-target.refined-properties): expand composites in the 'requirements' property-set.
Patch from Paul Lin.
* tests/composite.py: New test.
[SVN r20615]
Thanks to Peter Schoen for bugreport.
* new/project.jam (initialize): Set 'project-root-module' attribute.
* new/project_root.py: New test.
[SVN r19899]
* jam_src/builtins.c: New builtins IMPORT_MODULE and IMPORTED_MODULES.
jam_src/rules.c: (bindrule): Refactor. (lookup_rule): New function.
* kernel/modules.jam: Make use of IMPORT_MODULE.
[SVN r19422]
it included MSVC...
* new/toolset.jam:
Allow action names with dots, so that we can set flags for
gcc.compile.c, gcc.compile and gcc and combine those flags.
* tools/gcc.jam: Use 'gcc' for compiling C files. There's still a problem:
'init' rules does not allow to configure name of C compiler. Also, don't
declare flags individually for gcc.link and gcc.link-dll.
* tools/borland.jam: Force C++ compile when needed.
[SVN r18774]
metacharacters, Boost.Build misbehaved.
* new/path.jam
(all-parents): Don't use regex to strip path prefix, use a more robust
approach.
* test/bad_dirname.py: New test.
[SVN r18576]
* new/virtual-target.jam
(null-action): Pass '.no-action' as action name, not 'no-action'. The
action name is really dummy, it's not used at all. However, when it does
not include dot, the smart 'action' ctor will assume it's local and prepend
module name to it. The calling module will be 'null-action' instance module,
always unique, and as result, no two targets with null actions will be
equal, as far as 'virtual-target.register' is concerned.
[SVN r18424]
* handle the absence of QT more gracefully
* flush stdout after each test so that emacs shows progress
****** Commented out tests which appear to be failing outside my control ******
[SVN r18410]
