[toplevel] Gas install name problem from autoconf 2.5x

[toplevel] Gas install name problem from autoconf 2.5x

[Daniel Jacobowitz]

I've gotten a report that gas now installs after a native build as
$(target_alias)-as.  This is presumably the one consequence of autoconf
2.5x's "specify absolutely nothing on the command line unless absolutely
necessary" policy.

I see two basic choices:
  - Override AC_CANONICAL_TARGET.
  - Always pass down --program-transform-name from the top level.

I think the latter is the way to go.  Any other opinions?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [toplevel] Gas install name problem from autoconf 2.5x

[Ian Lance Taylor]

Daniel Jacobowitz <drow@mvista.com> writes:

> I've gotten a report that gas now installs after a native build as
> $(target_alias)-as.  This is presumably the one consequence of autoconf
> 2.5x's "specify absolutely nothing on the command line unless absolutely
> necessary" policy.
> 
> I see two basic choices:
>   - Override AC_CANONICAL_TARGET.
>   - Always pass down --program-transform-name from the top level.
> 
> I think the latter is the way to go.  Any other opinions?

Is this yet another quiet autoconf change?  Formerly,
program_transform_name didn't do anything in the case where host_alias
and target_alias were the same.

I see that now it does something whenever target_alias is set.  I
can't see any documentation about this behaviour, but then the old
behaviour probably wasn't documented either.

I guess my question is: why is --target being passed down from the top
level in the native case?  I thought part of the autoconf conversion
was that the top level had to stop passing down --target all the time.

Anyhow, I think it would be moderately useful if `make install' worked
correctly in the gas subdirectory.  I don't know what is required to
make that happen.

Ian

Re: [toplevel] Gas install name problem from autoconf 2.5x

[Daniel Jacobowitz]

On Tue, Sep 02, 2003 at 09:40:56PM -0700, Ian Lance Taylor wrote:
> Daniel Jacobowitz <drow@mvista.com> writes:
> 
> > I've gotten a report that gas now installs after a native build as
> > $(target_alias)-as.  This is presumably the one consequence of autoconf
> > 2.5x's "specify absolutely nothing on the command line unless absolutely
> > necessary" policy.
> > 
> > I see two basic choices:
> >   - Override AC_CANONICAL_TARGET.
> >   - Always pass down --program-transform-name from the top level.
> > 
> > I think the latter is the way to go.  Any other opinions?
> 
> Is this yet another quiet autoconf change?  Formerly,
> program_transform_name didn't do anything in the case where host_alias
> and target_alias were the same.
> 
> I see that now it does something whenever target_alias is set.  I
> can't see any documentation about this behaviour, but then the old
> behaviour probably wasn't documented either.

Yes, that appears to be what's going on.

> I guess my question is: why is --target being passed down from the top
> level in the native case?  I thought part of the autoconf conversion
> was that the top level had to stop passing down --target all the time.
> 
> Anyhow, I think it would be moderately useful if `make install' worked
> correctly in the gas subdirectory.  I don't know what is required to
> make that happen.

Well, up to now, it didn't make any difference.  We could use the third
option:
  - Don't pass $target unless it was given on the command line.

This is definitely a good idea, but I was going to do that after most
directories had converted.  Enough people configure native compilers
now by giving all of build/host/target that I'm not very happy with the
solution.

How do we feel about migrating towards the new autoconf definitions -
i.e. anything with --host is cross-compiled, anything with --target is
a cross-compiler.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [toplevel] Gas install name problem from autoconf 2.5x

[DJ Delorie]

> How do we feel about migrating towards the new autoconf definitions -
> i.e. anything with --host is cross-compiled, anything with --target is
> a cross-compiler.

That breaks cases where you use --host to override config.guess's idea
of the system name, i.e. to provide a canonical triplet across a range
of build hosts that are compatible yet guess to different triples.

It also breaks automated builds which aren't smart enough to even
consider the possibility that you won't provide all three.  Er, like
one of mine, which is table driven.

We should be liberal in what we accept.  We once discussed
auto-detecting which autoconf each subdirectory used, and filtering
command lines accordingly.  I suspect this is still a good idea.
Don't expect the user to be smart about this, they won't be.

Re: [toplevel] Gas install name problem from autoconf 2.5x

[Ian Lance Taylor]

Daniel Jacobowitz <drow@mvista.com> writes:

> Well, up to now, it didn't make any difference.  We could use the third
> option:
>   - Don't pass $target unless it was given on the command line.
> 
> This is definitely a good idea, but I was going to do that after most
> directories had converted.

I think that to make things work with the current autoconf you need to
know which autoconf is being used in the subdirectory.

> Enough people configure native compilers
> now by giving all of build/host/target that I'm not very happy with the
> solution.

Well, that's a problem.

> How do we feel about migrating towards the new autoconf definitions -
> i.e. anything with --host is cross-compiled, anything with --target is
> a cross-compiler.

I've never felt particularly good about it, but the autoconf
maintainers seem determined about it.  I think our choices are either
to adopt their scheme, or to use a patched autoconf.

Looking at the autoconf archives, I see that I grumbled about the
change to --program-prefix/--program-transform-name before:
    http://mail.gnu.org/archive/html/autoconf/2002-01/msg00053.html
Here is the rest of the thread:
    http://mail.gnu.org/archive/html/autoconf/2002-02/msg00060.html
Basically the autoconf maintainers say the new way is right, and
they're sorry that people have to change.

I don't know where the original discussion about this was.

Ian

Re: [toplevel] Gas install name problem from autoconf 2.5x

[Ian Lance Taylor]

DJ Delorie <dj@redhat.com> writes:

> > How do we feel about migrating towards the new autoconf definitions -
> > i.e. anything with --host is cross-compiled, anything with --target is
> > a cross-compiler.
> 
> That breaks cases where you use --host to override config.guess's idea
> of the system name, i.e. to provide a canonical triplet across a range
> of build hosts that are compatible yet guess to different triples.

The new scheme is to specify --build instead.  $host defaults to
$build.

> It also breaks automated builds which aren't smart enough to even
> consider the possibility that you won't provide all three.  Er, like
> one of mine, which is table driven.

Yes.

> We should be liberal in what we accept.  We once discussed
> auto-detecting which autoconf each subdirectory used, and filtering
> command lines accordingly.  I suspect this is still a good idea.
> Don't expect the user to be smart about this, they won't be.

I think that is what is required until everything is updated.

It still leaves the top level problem--the behaviour changes at the
top level, which means that users have to change.

Ian

Re: [toplevel] Gas install name problem from autoconf 2.5x

[Daniel Jacobowitz]

On Wed, Sep 03, 2003 at 09:13:45AM -0700, Ian Lance Taylor wrote:
> DJ Delorie <dj@redhat.com> writes:
> 
> > > How do we feel about migrating towards the new autoconf definitions -
> > > i.e. anything with --host is cross-compiled, anything with --target is
> > > a cross-compiler.
> > 
> > That breaks cases where you use --host to override config.guess's idea
> > of the system name, i.e. to provide a canonical triplet across a range
> > of build hosts that are compatible yet guess to different triples.
> 
> The new scheme is to specify --build instead.  $host defaults to
> $build.

Unfortunately I'm not sure that this works with older versions of
autoconf.  In fact I'm pretty sure that it doesn't.

> > It also breaks automated builds which aren't smart enough to even
> > consider the possibility that you won't provide all three.  Er, like
> > one of mine, which is table driven.
> 
> Yes.

Yes.  This will break:
 - the test scripts I've been using for testing autoconf udpates.  Isn't it
   ironic?
 - All of MontaVista's toolchain build scripts.

I can't say that I'm thrilled.

> > We should be liberal in what we accept.  We once discussed
> > auto-detecting which autoconf each subdirectory used, and filtering
> > command lines accordingly.  I suspect this is still a good idea.
> > Don't expect the user to be smart about this, they won't be.
> 
> I think that is what is required until everything is updated.
> 
> It still leaves the top level problem--the behaviour changes at the
> top level, which means that users have to change.

I think that, as you said, we do not have any choice.  The alternative
is forking autoconf to reverse the decision, and I certainly don't
want to do that.

What do folks think about biting the bullet, documenting the new
semantics, and trying to get every affected directory before the next
releases of binutils/gcc/gdb?  I believe that none of the other
projects in src will be affected, they're all target apps or target
libraries.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [toplevel] Gas install name problem from autoconf 2.5x

[Alexandre Oliva]

On Sep  3, 2003, Daniel Jacobowitz <drow@mvista.com> wrote:

> I've gotten a report that gas now installs after a native build as
> $(target_alias)-as.  This is presumably the one consequence of autoconf
> 2.5x's "specify absolutely nothing on the command line unless absolutely
> necessary" policy.

Which is why I wrote, when we started talking about moving to autoconf
2.57, that toplevel should pass different flags to sub-directories
depending on whether they use autoconf 2.5x or 2.13.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: [toplevel] Gas install name problem from autoconf 2.5x

[Alexandre Oliva]

On Sep  3, 2003, Daniel Jacobowitz <drow@mvista.com> wrote:

>> The new scheme is to specify --build instead.  $host defaults to
>> $build.

> Unfortunately I'm not sure that this works with older versions of
> autoconf.  In fact I'm pretty sure that it doesn't.

It doesn't.  You (toplev) have to know what (subdir's) autoconf you're
talking to.

> I think that, as you said, we do not have any choice.  The alternative
> is forking autoconf to reverse the decision, and I certainly don't
> want to do that.

I think the autoconf decision was sound (although I disliked it
because I could see the amount of disruption it would cause), but it's
done, so we'll have to choose a date to call flag day.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: [toplevel] Gas install name problem from autoconf 2.5x

[Daniel Jacobowitz]

On Thu, Sep 04, 2003 at 02:40:40AM -0300, Alexandre Oliva wrote:
> On Sep  3, 2003, Daniel Jacobowitz <drow@mvista.com> wrote:
> 
> >> The new scheme is to specify --build instead.  $host defaults to
> >> $build.
> 
> > Unfortunately I'm not sure that this works with older versions of
> > autoconf.  In fact I'm pretty sure that it doesn't.
> 
> It doesn't.  You (toplev) have to know what (subdir's) autoconf you're
> talking to.
> 
> > I think that, as you said, we do not have any choice.  The alternative
> > is forking autoconf to reverse the decision, and I certainly don't
> > want to do that.
> 
> I think the autoconf decision was sound (although I disliked it
> because I could see the amount of disruption it would cause), but it's
> done, so we'll have to choose a date to call flag day.

In the mean time, how about a different solution?

I would like to explicitly pass --program-transform-name from the
toplevel to subdirectories, when configure implicitly generates it. 
How does that sound?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [toplevel] Gas install name problem from autoconf 2.5x

[Ian Lance Taylor]

Daniel Jacobowitz <drow@mvista.com> writes:

> I would like to explicitly pass --program-transform-name from the
> toplevel to subdirectories, when configure implicitly generates it. 
> How does that sound?

While that would fix one problem, I suspect there will be other
problems.

The new autoconf simply behaves differently with respect to command
line options.  I suspect that trying to finesse this behaviour will
lead to trouble.  Better to adjust the command line options depending
on the version of autoconf used in the subdirectory, or convert all
the configure scripts at once.

Ian

Re: [toplevel] Gas install name problem from autoconf 2.5x

[Daniel Jacobowitz]

On Sat, Sep 06, 2003 at 09:08:45PM -0700, Ian Lance Taylor wrote:
> Daniel Jacobowitz <drow@mvista.com> writes:
> 
> > I would like to explicitly pass --program-transform-name from the
> > toplevel to subdirectories, when configure implicitly generates it. 
> > How does that sound?
> 
> While that would fix one problem, I suspect there will be other
> problems.
> 
> The new autoconf simply behaves differently with respect to command
> line options.  I suspect that trying to finesse this behaviour will
> lead to trouble.  Better to adjust the command line options depending
> on the version of autoconf used in the subdirectory, or convert all
> the configure scripts at once.

Converting all the configure scripts at once isn't going to happen.

And adjusting the command lines isn't going to solve the problem,
either.  Consider that a lot of people are used to explicitly
specifying --host/--build/--target.  They'll now get gas installed as
<target>-gas and gcc installed as gcc.  Plus, you can't even use the
new-style arguments to configure, because the top level hasn't been
converted; you must still give it the old-style arguments or it'll draw
the wrong conclusions.

Oh, and I just noticed: ./configure i686-linux will now produce
i686-linux-gas and gcc too.  Nothing we can do about that unless we
want to manufacture appropriate arguments from whole cloth for each
configure type.

The only other difference besides this one and the cross-compilation
mode one that I've been able to find is:
2.13:
if test $host != $build; then
  ac_tool_prefix=${host_alias}-
else
  ac_tool_prefix=
fi

2.57:
test -n "$host_alias" && ac_tool_prefix=$host_alias-

But in both cases it will fall back to unprefixed versions if those
aren't found, so I don't expect this to be a big problem.  And I do
expect all configure scripts to be converted, at some point, before any
new major releases from these repositories.

Anyway, actions, words, all that.  Here is a patch to compute
program-transform-name in the top level and pass it down.  This patch
preserves the 2.13 behavior, because at the moment that's easier; then,
in a few more months when the bulk of the affected directories have
been converted, we can either remove it or update it to the 2.5x
behavior.  Just rebuilding the toplevel configure script with 2.5x will
change the behavior for all subdirectories consistently, converted or
not.  Thoughts?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

2003-09-07  Daniel Jacobowitz  <drow@mvista.com>

	* configure.in: Pass a computed --program-transform-name
	to subconfigures.

Index: configure.in
===================================================================
RCS file: /big/fsf/rsync/src-cvs/src/configure.in,v
retrieving revision 1.184
diff -u -p -r1.184 configure.in
--- configure.in	4 Sep 2003 12:33:44 -0000	1.184
+++ configure.in	7 Sep 2003 17:28:14 -0000
@@ -1766,7 +1766,9 @@ AC_SUBST_FILE(serialization_dependencies
 
 # Base args.  Strip norecursion, cache-file, srcdir, host, build,
 # target and nonopt.  These are the ones we might not want to pass
-# down to subconfigures.
+# down to subconfigures.  Also strip program-prefix, program-suffix,
+# and program-transform-name, so that we can pass down a consistent
+# program-transform-name.
 cat <<\EOF_SED > conftestsed
 s/ --no[[^ ]]* / /
 s/ --c[[a-z-]]*[[= ]][[^ ]]* / /
@@ -1774,16 +1776,34 @@ s/ --sr[[a-z-]]*[[= ]][[^ ]]* / /
 s/ --ho[[a-z-]]*[[= ]][[^ ]]* / /
 s/ --bu[[a-z-]]*[[= ]][[^ ]]* / /
 s/ --t[[a-z-]]*[[= ]][[^ ]]* / /
+s/ --program-[[pst]][[a-z-]]*[[= ]][[^ ]]* / /
 s/ -cache-file[[= ]][[^ ]]* / /
 s/ -srcdir[[= ]][[^ ]]* / /
 s/ -host[[= ]][[^ ]]* / /
 s/ -build[[= ]][[^ ]]* / /
 s/ -target[[= ]][[^ ]]* / /
+s/ -program-prefix[[= ]][[^ ]]* / /
+s/ -program-suffix[[= ]][[^ ]]* / /
+s/ -program-transform-name[[= ]][[^ ]]* / /
 s/ [[^' -][^ ]*] / /
 s/^ *//;s/ *$//
 s,\\,\\\\,g; s,\$,$$,g
 EOF_SED
 baseargs=`echo " ${ac_configure_args} " | sed -f conftestsed`
+rm -f conftestsed
+
+# Add in --program-transform-name, after --program-prefix and
+# --program-suffix have been applied to it.
+cat <<\EOF_SED > conftestsed
+s,\\,\\\\,g; s,\$,$$,g
+EOF_SED
+gcc_transform_name="${program_transform_name}"
+# Autoconf expects s,x,x, as the default.  If we want subdirectory configure
+# scripts to obey this transformation, we need to modify it slightly.
+if test "${gcc_transform_name}" = s,x,x,; then
+  gcc_transform_name=s,y,y,
+fi
+baseargs="$baseargs --program-transform-name=`echo ${gcc_transform_name} | sed -f conftestsed`"
 rm -f conftestsed
 
 # For the build-side libraries, we just need to pretend we're native,