enviroment variables in the list of values. No it's possible to add
an element to a variable.
* build/project.jam: Remove obsolete test.
* build/toolset.jam (find-property-subset): No longer local,
so that test can call it.
* test/test.jam: Import 'print' and 'common'.
* util/print.jam: Comment out failing unit test.
[SVN r26413]
* build/targets.jam
(project-target.find): Better error reporting.
* build/project.jam
(load-jamfile): Use 'path.native' when loading Jamfile,
otherwise, target id with absolute directory name won't
work for Windows.
[SVN r26271]
(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]
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]
* v2/tools/gcc.jam
(init): parse the new options and call the new rule.
(init-link-flags): new rule. Initialize flags based on linker type.
put back -minpure-text
* v2/test/conditionals.py
small modification to avoid empty binaries.
Patch from Andre Hentz.
[SVN r25764]
would force us to relink all libraries when staging.
Now that libraries do not hardcode dll paths, add a check that correct
-rpath-link options are added. When staging, we don't hardcode-dll-paths,
and libraries never hardcode dll paths, so if there's a long chain of
libraries, we should add -rpath-link, otherwise the linker won't find
the dynamic libraries and will complain.
[SVN r25756]
lib png : z : <name>png ;
lib z : : <name>z ;
now works: if you link to 'png' you'll also link to 'z'.
lib png : z : <file>png.a ;
lib z : : <file>z.a ;
now works too. The 'prebuilt.jam' modules which used to handle <file> for
all target kinds is now removed.
[SVN r25703]
* 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]
'rank' for each viable generator, we use explicit information of the
form 'generator A is better than generator B', which is provided by
the user. The obvious goal is to fix 'custom_generator' failure on
msvc, but generally, I'm fixing BB76 -- which says that current generators
selection is very broken.
[SVN r25361]
msvc, 0 is returned and that broke the test. But really, we're interested
only if user-defined generator is run, not that the result is compiled.
[SVN r24779]
(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]
'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]
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]
