- Copy the <linkflags> feature when relinking targets.
- Don't install typeless targets if explicit list of
allowed types is specified.
- Fix the 'rename' rule to handle <runtime-debugging> feature.
[SVN r33057]
1. If when generating something, we find more that one suitable generators,
run them and more then one return something, immediately report ambiguity.
Don't care if the produced targets are the same. This is better that
running several generators all the time, performance wise.
2. Remove the notion of 'intermediate' virtual-targets. IIRC, they were used
to prevent staging of RSP files, and we don't stage them anyway now.
[SVN r29491]
- Drop separate 'suffix' field in file targets. Store suffix as part of
the name' field. This avoids the need to copy the suffix field and the
name everywhere.
- Do not pass generated targets to constructor of 'action'. Instead,
pass the acton to constructor of target.
[SVN r26778]
stage a1 : a1.txt : <location>dist ;
stage a2 : a2.txt : <location>dist <dependency>a1 ;
The problem is that 'a1' is requested with <os>LINUX but the returned target
have <location>dist as the only property, which causes this bogus warning.
[SVN r26421]
* tools/stage.jam
(copy-file, relink-file): Add stage's dependency properies to
the staged targets properties, so that <dependency> is copied too.
* test/stage.py: New test.
[SVN r26420]
* tools/stage.jam
(stage-shared-linking-generator.run): Don't hardcode 'so' suffix.
* build/virtual-target.jam
(abstract-file-target.suffix): Compute and return the real suffix
that will be used. Previously, it would return something only if the
suffix was explicitly set.
[SVN r26414]
* tools/stage.jam
(stage-target-class.targets-to-stage): New rule, partly extracted
from construct, and former 'select-included'.
(stage-target-class.construct): Cleanup.
* build/virtual-target.jam
(file-target.path): If <location> feature is present, use the
value as the path.
[SVN r26411]
* build/targets.jam (generate-realy):
After applying tag, we used to 'temporary' change self.name,
which is horrible. How pass the name to 'construct'.
(construct): New parameter 'name'.
(tag-name): New rule, extracted from basic-target. This needs to be
separate rule so that we can call it from 'stage'. Check for a value of
from '@something' and interpret 'something' as a rule which returns the
new name.
[SVN r26408]
shared libraries when needed.
* tools/stage.jam
(copy-file, relink-file): New rules, extracted from other classes.
(STAGED_SHARED_LIB): New type.
(stage-shared-lib-generator): New class
[SVN r26399]
as the first elements of result. Those usage requirements will be combined
with explicitly specified for the main target.
This is yet another step towards making 'main target classes' unnecessary.
* build/generators.jam
(try-one-generator): Check if generator returned usage requirements or not.
(construct): Make sure first element of result is always property set.
(many other methods): Induced changes
* tools/builtin.jam
(exe-target-class, lib-target-class): Remove.
(linking-generator, seached-lib-generator): Compute usage requirements.
(archiving-generator): New class
[SVN r26192]
property, since it's typically used when only headers are used.
* build/virtual-target.jam (subvariant.all-referenced-targets): Return
the names of properties.
* tools/stage.jam (stage-target-class.collect-targets): Filter out <use>
Thanks to Jurgen Hunold for the bug report.
[SVN r26052]
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]
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]
* tools/stage.jam
(update-location,construct-special-target,construct-regular-target): New
methods
(construct): Rewrite in terms of the above methods.
Patch from Pedro Ferreira.
[SVN r21318]
