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]
Otherwise, the added path elements won't be seen when loading user-config.jam
and site-config.jam and we'll get error when those files are present only
in V2 directories.
[SVN r29360]
Not sure why it worked this way in the first place. The problem is that
after inheriting parent rules no longer have access to variables in original
module, like "RM", and no longer work.
[SVN r29325]
Removed flotsam from modules.h
Bind all environment variables, without any preprocessing for quotes,
spaces, or path separators, into the .ENVIRON module.
[SVN r29277]
I think that Dave committed then unintentionally in revision 1.36 and they
cause C++ files to be always recompiled. A better version is in the works
but cannot be committed yet, so I'll just restore the previous one for now.
[SVN r29198]
That was an old hack which was only needed in one context -- when we
passed both Jamroot and jamroot as patterns, got back Jamroot and jamroot
(because windows is case-insensitive and reports that both exist), and get
confused.
Calling 'unique' does not harm in most cases, but in Boost Jamfiles we glob
for all headers, and O(n^2) algorithm used by unique considerably slows us.
[SVN r29187]
The problem with the previous implementation is that it would iterate
over all elements in a dir even if 'pattern' had no metacharacters. First,
that was slow -- if you handed
/cygdrive/w/My Documents/boost/test/a.cpp
to it, it would crawl all the way to the top, listing each directory and
checking each file. Second, it would fail, because Cygwin is broken and
does not show 'cygdrive' is the list of directory elements of '/'.
Now we check if a pattern has metacharacters, and if not, just do
a simple 'timestamp' call.
The new glob is implemented as new 'GLOB-RECURSIVELY' builtin. I've decided
to use builtin since otherwise, we'd need 'does this name exist' builtin,
and if we need new builtin, why don't implement all globbing in core.
[SVN r29163]
