rather then only defined on first.
The previous behaviour did not work when there were "default-build" attribute
on project and two alternatives for a main target.
Patch from Michael Stevens.
[SVN r19303]
* new/targets.jam
(project-target.add-alternative): New rule.
(project-target.build-main-targets): New rule.
(project-target.generate, project-target.main-target,
project-target.has-main-target): Call 'build-main-targets'
(project-target.rename-main-target): Remove.
(main-target-sources): Use 'rename', not project.rename-main-target.
(main-target-alternative): Simplify.
* test/inline.py: Test for fix.
[SVN r19245]
* new/builtin.jam
(lib-generator): Remove.
(lib-target-class): New class. Target class is more powerfull then
generator, here.
* new/generators.jam
(construct): New argument 'return-all'.
* bew/property-set.jam
(property-set.add-raw): New method.
[SVN r18917]
not by project attribute. The problem with the previous interface was
that it was not possible to mark target as explicit anywhere else,
such as in helper module which declares target in project module, or
in toolset module.
* new/targets.jam
(project-target.mark-target-as-explicit): New rule
(project-target.targets-to-build): Use self.explicit-targets.
* new/project.jam
(project-attributes.set): Don't allow 'explicit-targets'.
[SVN r18900]
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]
* new/project-root.jam (project-root-context.project): New rule
(find-project-rule): New rule, factored out of 'load' so that it can
be used elsewhere.
* new/project.jam (find): When project is not yet known, try loading
project-root, not only Jamfile.
[SVN r18759]
are communiated via return value of 'abstract-target.generate', not as
attribute of virtual target. The advantage is that we can return usage
requirements, even if no targets were created.
Also, usage requirements is not really attribute of virtual target. If several
virtual targets are created for one main target, the previous code would set
the same usage requirements on all virtual targets.
[SVN r18689]
* new/project.jam
(lookup) Don't support project location in front of "@".
(lookup-with-load): Remove.
(find): New rule.
(find-target): move to...
* new/target.jam
(find): Here. And simplify.
[SVN r18667]
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]
build-system.jam - moved from tools/build/new to tools/build
boost-build.jam - moved from tools/build/new to tools/build/kernel
bootstrap.jam
errors.jam
modules.jam
test/BoostBuild.py - adjusted for the above modification
test/boost-build.jam
project-root.jam - renamed to "project-roots.jam" to avoid confusion
and conflict with the user's project-root.jam file
project.jam - adjusted for the above renaming
test/project-test1/project-test1.jam
type.jam - broke a circular module dependency
[SVN r18575]
* new/project.jam
(inherit-attribute): New rule, extracted from 'initialize'.
(initialize): Allow 'jamfile' parameter to be empty, in which case
the project is 'standalone'.
[SVN r18544]
they are located. The problem with using the directory name is that we might
want toolset modules to act as project, and directory name is not unique then.
We might even want to declare two projects in the same module.
[SVN r18542]
* new/stage.jam
(stage-target-class.construct): Pass the result via
'virtual-target.register'. I wonder if virtual targets should
be create via 'virtual-target.create' which will invoke
'virtual-target.register' internally. Passing via 'register' was forgotten
in many places.
* test/stage.py: New test.
[SVN r18497]
default build was stored as plain list, and implied properties were not
converted. E.g. we had "debug release", not "<variant>debug <variant>release",
which was assumed.
* new/targets.jam
(main-target, basic-target): Store 'property-set' as default-build
attribute.
(main-target-default-build): Use 'property-set.create-with-validation'.
* new/property-set.jam
(create-with-validation): New rule.
* test/default_build.py: More tests.
[SVN r18436]
translation. Cleaned up indentation and idiomatic use of string.
* index.html - documented recent features including VARNAMES and
DELETE_MODULE
* borland.jam, msvc.jam - use the new :W modifier to simplify
code (but only somewhat)
* BoostBuild.py - ignore MSVC .ilk files under Cygwin and NT
[SVN r18434]
Consequently rolled back the workaround in make_rule.py
* Added new indirect rule invocation module for encoding the module to
invoke a rule from as well as the exact name to invoke it by, and
for subsequent invocation.
* Fixed module __test__ rules so they really do execute in a separate
module. Associated tweaks to __test__ in path.jam
[SVN r18427]
* 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]
