Yes, this seems to meet the needs I expressed. Thanks, Jan
>>> Paolo Bonzini <[EMAIL PROTECTED]> 23.12.05 10:10:01 >>>
> One appropriate default for --with-build-tools could be the same as
> the defaults for --program-transform-name. A default native build
> would use 'as', a default cross build would use '$target-as'. Most
> people using --program-prefix would probably also pass the same
value
> to --with-build-tools.
So --with-build-tools would be a *prefix* and not a path in which to
find it?
I have a prototype patch that follows this logic:
1) if not a Canadian cross and the appropriate directory is being built
as a host module, use it. So combined trees are not affected, of
course, by the patch.
2) look into the --with-build-tools path, for both a Canadian cross and
a native build. This defaults to $exec_prefix/$target/bin, so the
default build tools (used in autoconf tests and by the being-built GCC)
would be, if found, something like
/usr/local/i686-pc-linux-gnu/bin/{ar,as,ld,...}. These would be
"naked"
names, not $target-prefixed, even when building a cross (because they
are in a directory named after the target).
3) in a native build we try to use the host tool
4) if no host tool is found, we look for a pre-installed tool. The
macro NCN_STRICT_CHECK_TARGET_TOOLS imposes $target-prefixed names for
cross builds, while on a native build a "naked" name would be okay as
well.
Step 2 is new. The previous logic covers step 1, 3, 4.
I believe that this is covering Jan's use case. If it covers Dan's as
well, I'm going to post the patch in a few hours or else in the new
year
(in the meanwhile, there are other toplevel patches to review, i.e.
parts 2/4 and 3/4)...
We also have the problem of backwards compatibility. I can try to work
out a patch to implement --with-build-tools in 4.0 and 4.1 (with the
new
logic kicking in only if the option is specified, of course).
Paolo
