"user-config.jam", the result was "h:\\user-config.jam", which was not
found.
* jam_src/pathunix.c (path_build): Check if root ends with slash before
adding yet another one. Simply similiar check for directory element.
Thanks to Jurgen Hunold for the bug report.
[SVN r25909]
are configured.
* tools/gcc.jam (init-link-flags): New parameter 'toolset'.
* tools/darwin.jam (init): Move flags inheriting out of here
* tools/intel-linux.jam (init): Likewise.
[SVN r25817]
* tools/gcc.jam
(init): passing $(condition) to init-link-flags
(init-link-flags): now takes new condition parameter
moved common flags out of it
* tools/intel-linux.jam
(init): moved call to inherit-flags into it because we need to call
gcc.init-link-flags with the 'condition' parameter.
* tools/darwin.jam
(init): moved call to inherit-flags into it because we need to call
gcc.init-link-flags with the 'condition' parameter.
Fixes related to init-link-flags
* tools/gcc.jam
(init): passing $(condition) to init-link-flags
(init-link-flags): now takes new condition parameter
moved common flags out of it
* tools/intel-linux.jam
(init): moved call to inherit-flags into it because we need to call
gcc.init-link-flags with the 'condition' parameter.
* tools/darwin.jam
(init): moved call to inherit-flags into it because we need to call
gcc.init-link-flags with the 'condition' parameter.
Patch from Andre Hentz.
[SVN r25816]
a feature:
flags gcc.link RPATH_LINK <toolset>gcc-3.3 : <xdll-path> ;
Previously, we could either specify condition or <xdll-path>.
Also, kill support for 'prepare-target' in toolset module, since it's not
used.
[SVN r25802]
write
using gcc : ... : ... : <cxxflags>foo <linkflags>bar ;
* tools/common.jam (handle-options): The login for setting the common
options.
[SVN r25767]
(check-tool): Try finding both first and the last element. This avoid
warning both in the case of "distcc g++", and in case of
'"set FOO=bar &&" como'.
(get-invocation-command): Returns the user-specified command even if
it can't be found anywere. This means user specified command will show
up in the command line, and even if it fails, it's less confusing than
command line with no compiler name at all.
[SVN r25765]
* 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]
In particular, this allows to explicitly link statically to some
libs, using <linkflags> feature. In static libs are specified at
the beginning of the command line, we'll just get link errors.
[SVN r25548]
of virtual targets, not the deep one with the 'str' method. The latter is
very slow
* tools/gcc.jam: Don't declare gcc.link and gcc.link.dll generators, as
they are already inherited from unix.jam. If we declare them, then for
each targets, the whole generation process is run twice. As result,
select-alternative is called for each target, and due to sloweness of
'str' the performance is horrible.
The net result is that running time on one testcase is down from 1580 secs
to less than 10.
[SVN r25512]
'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]
libraries in a chain. E.g. in app -> a.so -> b.so, we need to pass
the path to b.so to the linker so that it can verify that all symbols
asked by 'app' and 'b.so' are present.
[SVN r25003]
