* 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]
* build/generators.jam
(generator.generated-targets): Comment the desired semantics.
* util/utility.jam
(basename): Take the part till the last dot, not the first.
[SVN r27374]
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]
'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]
* new/generators.jam
(generator.__init__): Use parallel lists to store prefixes and postfixes
for a name, not mapping with type as a key, since type is not unique.
(generator.generated-targets): Adjust.
[SVN r19990]
* boost_build_v2.html: Document new option.
* new/generators.jam (find-viable-generators): Revert part of Dave's
commit, essentially disabling finding base type generators.
This part breaks a test, and need to be thinked about.
* new/errors.jam: Handle "--no-error-backtrace" option.
* test/project_test4.py: Adjust for new error syntax.
[SVN r16233]
* new/builtin.jam: Make 'obj' main type.
* new/generators-test/*: Try compiling the same CPP file with
different defines and linking in the same exe.
[SVN r15649]
* virtual-target.jam (virtual-target.actualize): Accept
'scanner' parameter and create different actual targets
for different values of that parameter.
(virtual-target.includes): Remove.
(binding): New rule
(remember-binding): New rule.
* type.jam (set-scanner): New rule. (get-scanner): New rule.
* scanner.jam: New file.
* class.jam (__init__): Define __name__ in class scopes.
* builtin.jam (c-scanner): New scanner class, associated with CPP
files.
[SVN r15644]
- Got rid of vectors of vectors in generators code. That was not only slow, it
was also troublesome.
- Started work on transformation caching. Works but needs review/cleanup.
[SVN r15465]
prevents complining the same source twice with the same properties.
Also allow generators to change source names using patterns.
* new/generators.jam (generator): Accept name patterns together with
target types.
(generator.generated-targets): Use name patterns. Transform generated
targets with 'virtual-targets.register', to eliminate duplicate
virtual targets.
[SVN r15302]