in favour of the latter (toolset.prebuilt). This cuts down the number
of generator invocations for prebuilt target and is more clear.
Thanks to Mark Evans for pointing this out.
[SVN r32952]
the lib rule, e.g.:
lib foo : : <conditional>@sources ;
Prior to the patch, this was treating the library as a prebuilt
library because of the absence of any source arguments. Thus
nothing would get built.
* tools/builtin.jam
(lib-generator.run): Added additional constraint when setting
library type to SEARCHED_LIB.
Patch from Mark Evans.
[SVN r32880]
'search' property. This makes sure that linking againsts searched library
in custom directory works on gcc, and that proper run-time library search
path is set by 'unit-test' and 'run' rule.
[SVN r32342]
When a library is present in sources of a static library, return it
to dependents via usage requirements, not by adding it to the list
of created targets.
[SVN r29362]
* If a generator was given a source it could not handle, it used to return
that source together with generated targets. This was nice for some use
cases, but no very nice for others, and this behaviour could not be turned
off. One use case where it worked bad was:
lib plugin : plugin.cpp helper ;
lib helper : helper.cpp ;
On windows, 'plugin' would link to the 'import library' and pass the DLL
target though. So, when installing 'plugin', we'd also install 'helper.dll',
and it was not possible to do anything about it.
* If we asked generators.construct to produce sources of type CPP,
and the selected generator produced both targets of type CPP, and of
some other type, we'd try again to convert those other targets to CPP.
This simply complicated the logic for no good reason.
* Most generator function had 'multiple' parameter, which function
was long forgotten by anybody.
As a bit of history, I believe some of the above decisions were due to a
certain use case:
CPP <------- WHL
\
WD
/
CPP <------- DLP
Here, a source file is converted to two targets with one command, and each
produced file is converted to CPP. Our generators search would notice that
there are two generators for CPP: the WHL->CPP and DPL->CPP
generators. Neither is better that the other so both are tried, and produce
(CPP, DPL) and (CPP, WHL) pairs of targets. To avoid reporting an ambiguity,
we'd try to convert, DLP to CPP and WHL to CPP, do it successfully, notice
that produced targets are the same and decide that there's no ambiguity.
However, this is rather complex logic for a relatively rare case. It can
be handled by writing another WD->CPP generator that would handle
disambiguation itself.
This commit has one user-visible change. The code:
exe a : a.cpp b ;
obj b : b.cpp helper;
lib helper ;
No longer works -- the 'a' target won't link to 'helper'. However, this is
pretty stange code and worked before almost by accident.
[SVN r29361]
- 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]
Thanks to Toon Knapen for the bug report.
* tools/builtin.jam
(archiving-generator.run): Add <library> properties to sources.
* test/library_chain.py: New test.
[SVN r26447]
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]
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]
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]
