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

Reply via email to