(toplevel patch) Use canonical names for target_subdir, build_subdir.

(toplevel patch) Use canonical names for target_subdir, build_subdir.

[Nathanael Nerode]

Use the canonical build and target names for build_subdir and target_subdir.
This saves a tedious amount of work when we get around to autoconf 2.5x 
conversion (where build_alias and target_alias may be empty strings).

Built successfully on i686-pc-linux-gnu.  (But then, this should make no
difference at all in the native case.)

Built combined tree cross to i386-cygwin, and one to powerpc-linux.
They worked as well as they did before.

Did as much other testing as I could with the tremendous unreliability of
out-of-the-box cross builds.

This was an easy change to make, and a pain in the neck to test, due to
general breakage for crosses in src.

I wouldn't mind additional testing by people better at it than me.  I 
think I got everything which needs to change, but I'm not 100% sure.

(top level)
	* configure.in: Use canonical names for build_subdir, target_subdir.
	* configure: Regenerate.
(gcc)
	* configure.in: Use canonical names for build_subdir, target_subdir.
	* configure: Regenerate.
(gdb)
	* configure.in: Use canonical name for target_subdir.
	* configure: Regenerate.

Note that this doesn't always like to apply as a single 'patch'; it's usually
happier as three.

Index: configure.in
===================================================================
RCS file: /cvs/gcc/gcc/configure.in,v
retrieving revision 1.216
diff -u -r1.216 configure.in
--- configure.in	23 Jan 2003 22:32:25 -0000	1.216
+++ configure.in	23 Jan 2003 22:43:58 -0000
@@ -201,7 +201,7 @@
 
 # We always want to use the same name for this directory, so that dejagnu
 # can reliably find it.
-target_subdir=${target_alias}
+target_subdir=${target}
 
 if test ! -d ${target_subdir} ; then
   if mkdir ${target_subdir} ; then true
@@ -211,8 +211,7 @@
   fi
 fi
 
-build_prefix=build-
-build_subdir=${build_prefix}${build_alias}
+build_subdir=build-${build}
 
 if test x"${build_alias}" != x"${host}" ; then
   if test ! -d ${build_subdir} ; then
Index: gcc/configure.in
===================================================================
RCS file: /cvs/gcc/gcc/gcc/configure.in,v
retrieving revision 1.637
diff -u -r1.637 configure.in
--- gcc/configure.in	21 Jan 2003 13:45:07 -0000	1.637
+++ gcc/configure.in	23 Jan 2003 22:44:09 -0000
@@ -1028,7 +1028,7 @@
 	cd ..
 	rm -rf $tempdir
 	build_auto=auto-build.h
-	FORBUILD=../build-$build_alias
+	FORBUILD=../build-$build
 fi
 AC_SUBST(FORBUILD)
 
@@ -2712,7 +2712,7 @@
 host_canonical=${host}
 target_subdir=
 if test "${host}" != "${target}" ; then
-    target_subdir=${target_alias}/
+    target_subdir=${target}/
 fi
 AC_SUBST(build_canonical)
 AC_SUBST(host_canonical)
Index: gdb/configure.in
===================================================================
RCS file: /cvs/src/src/gdb/configure.in,v
retrieving revision 1.118
diff -u -r1.118 configure.in
--- gdb/configure.in	22 Jan 2003 23:50:35 -0000	1.118
+++ gdb/configure.in	23 Jan 2003 22:44:27 -0000
@@ -1204,7 +1204,7 @@
 # target_subdir is used by the testsuite to find the target libraries.
 target_subdir=
 if test "${host}" != "${target}"; then
-    target_subdir="${target_alias}/"
+    target_subdir="${target}/"
 fi
 AC_SUBST(target_subdir)
 

Re: (toplevel patch) Use canonical names for target_subdir, build_subdir.

[Alexandre Oliva]

On Jan 24, 2003, Nathanael Nerode <neroden@twcny.rr.com> wrote:

> Use the canonical build and target names for build_subdir and target_subdir.

Not ok.  athlon-linux-gnu is canonicalized to i686-linux-gnu, so we
can't use the same directories for both of them.  (Consider building a
compiler on athlon that must run on i686, or on the other way round).

I see where you're coming from, but we're really going to have to bite
the bullet and duplicate autoconf 2.5x's behavior WRT machine name
variables, or convince autoconf folks to give us some means to obtain
the defaulted values, which shouldn't be too hard.  Say, if configure
could set {build,host,target}_noncanonical to whatever autoconf 2.13
used to set as {build,host,target}_alias, we'd be all set.  Bonus
points of they actually agree to go back to setting the _alias
variables in a backward-compatible way, while setting _cmdline to
whatever was passed in the command line.

-- 
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 patch) Use canonical names for target_subdir, build_subdir.

[Nathanael Nerode]

Alexandre Oliva wrote:
> On Jan 24, 2003, Nathanael Nerode <neroden@twcny.rr.com> wrote:
> 
> 
>>Use the canonical build and target names for build_subdir and target_subdir.
> 
> 
> Not ok.  athlon-linux-gnu is canonicalized to i686-linux-gnu, so we
> can't use the same directories for both of them.  (Consider building a
> compiler on athlon that must run on i686, or on the other way round).
Eeech.  All right.

> I see where you're coming from, but we're really going to have to bite
> the bullet and duplicate autoconf 2.5x's behavior WRT machine name
You mean autoconf 2.13's behavior, I assume...

> variables, or convince autoconf folks to give us some means to obtain
> the defaulted values, which shouldn't be too hard.  Say, if configure
> could set {build,host,target}_noncanonical to whatever autoconf 2.13
> used to set as {build,host,target}_alias, we'd be all set.  Bonus
> points of they actually agree to go back to setting the _alias
> variables in a backward-compatible way, 
They won't, and frankly I agree with them.

 > while setting _cmdline to
> whatever was passed in the command line. 

OK.  I'll do this the easy way:  I'll write Autoconf macros which 
determine the "target_subdir" and "build_subdir" (exactly the same way 
they're determined now), put the macros in an include file, and rewrite 
the configure scripts to include it.  How does that sound?

--Nathanael

Re: (toplevel patch) Use canonical names for target_subdir, build_subdir.

[Alexandre Oliva]

On Jan 24, 2003, Nathanael Nerode <neroden@twcny.rr.com> wrote:

>> I see where you're coming from, but we're really going to have to bite
>> the bullet and duplicate autoconf 2.5x's behavior WRT machine name

> You mean autoconf 2.13's behavior, I assume...

No, I meant duplicating the logic that 2.5x uses to set canonical
names to propagate the corresponding non-canonical names.

> OK.  I'll do this the easy way:  I'll write Autoconf macros which
> determine the "target_subdir" and "build_subdir" (exactly the same way
> they're determined now), put the macros in an include file, and
> rewrite the configure scripts to include it.  How does that sound?

I fail to see the point, but if you want to take the code out into a
macro, don't let me stop you.

-- 
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 patch) Use canonical names for target_subdir, build_subdir.

[Andreas Schwab]

Nathanael Nerode <neroden@twcny.rr.com> writes:

> Use the canonical build and target names for build_subdir and target_subdir.
> This saves a tedious amount of work when we get around to autoconf 2.5x 
> conversion (where build_alias and target_alias may be empty strings).
> 
> Built successfully on i686-pc-linux-gnu.  (But then, this should make no
> difference at all in the native case.)

Did you try "make check"?  It's currently completely broken, see
gcc-testresults.

Andreas.

Re: (toplevel patch) Use canonical names for target_subdir, build_subdir.

[Phil Edwards]

On Sat, Jan 25, 2003 at 01:55:41AM +0100, Andreas Schwab wrote:
> Nathanael Nerode <neroden@twcny.rr.com> writes:
> 
> > Use the canonical build and target names for build_subdir and target_subdir.
> > This saves a tedious amount of work when we get around to autoconf 2.5x 
> > conversion (where build_alias and target_alias may be empty strings).
> > 
> > Built successfully on i686-pc-linux-gnu.  (But then, this should make no
> > difference at all in the native case.)
> 
> Did you try "make check"?  It's currently completely broken, see
> gcc-testresults.

Indeed.  I build on athlon_mp-pc-linux-gnu, and the target subdir just
moved out from underneath me...

(On the plus side, the toplevel configury is human-readable these days.  :-)
So it was easy to find and revert locally.  Thanks again for doing all that.)


Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002

Re: (toplevel patch) Use canonical names for target_subdir, build_subdir.

[Phil Edwards]

On Fri, Jan 24, 2003 at 02:50:21PM -0200, Alexandre Oliva wrote:
> On Jan 24, 2003, Nathanael Nerode <neroden@twcny.rr.com> wrote:
> 
> > Use the canonical build and target names for build_subdir and target_subdir.
> 
> Not ok.  athlon-linux-gnu is canonicalized to i686-linux-gnu, so we
> can't use the same directories for both of them.  (Consider building a
> compiler on athlon that must run on i686, or on the other way round).

So, is this going to be reverted or not?  It's destroying the testsuite
results.


Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002

Re: (toplevel patch) Use canonical names for target_subdir, build_subdir.

[Alexandre Oliva]

On Jan 26, 2003, Phil Edwards <phil@jaj.com> wrote:

> On Fri, Jan 24, 2003 at 02:50:21PM -0200, Alexandre Oliva wrote:
>> On Jan 24, 2003, Nathanael Nerode <neroden@twcny.rr.com> wrote:
>> 
>> > Use the canonical build and target names for build_subdir and target_subdir.
>> 
>> Not ok.  athlon-linux-gnu is canonicalized to i686-linux-gnu, so we
>> can't use the same directories for both of them.  (Consider building a
>> compiler on athlon that must run on i686, or on the other way round).

> So, is this going to be reverted or not?  It's destroying the testsuite
> results.

Please go ahead and revert it.  It must have gone in by mistake, since
it was explicitly rejected.

-- 
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 patch) Use canonical names for target_subdir, build_subdir.

[Phil Edwards]

On Sun, Jan 26, 2003 at 10:44:56AM -0200, Alexandre Oliva wrote:
> On Jan 26, 2003, Phil Edwards <phil@jaj.com> wrote:
> 
> > On Fri, Jan 24, 2003 at 02:50:21PM -0200, Alexandre Oliva wrote:
> >> On Jan 24, 2003, Nathanael Nerode <neroden@twcny.rr.com> wrote:
> >> 
> >> > Use the canonical build and target names for build_subdir and target_subdir.
> >> 
> >> Not ok.  athlon-linux-gnu is canonicalized to i686-linux-gnu, so we
> >> can't use the same directories for both of them.  (Consider building a
> >> compiler on athlon that must run on i686, or on the other way round).
> 
> > So, is this going to be reverted or not?  It's destroying the testsuite
> > results.
> 
> Please go ahead and revert it.  It must have gone in by mistake, since
> it was explicitly rejected.

Done as below.  Looking over the cvs log, I think Nathanael might have been
committed this by accident as part of reverting his rda stuff.  That would
explain why it was committed at the top level and not in the gcc directory.


2003-01-27  Phil Edwards  <pme@gcc.gnu.org>

	* configure.in:  Revert 24Jan change.
	* configure:  Regenerate.


Index: configure.in
===================================================================
RCS file: /cvs/gcc/gcc/configure.in,v
retrieving revision 1.217
diff -u -3 -p -r1.217 configure.in
--- configure.in	24 Jan 2003 00:39:39 -0000	1.217
+++ configure.in	27 Jan 2003 14:53:33 -0000
@@ -201,7 +201,7 @@ fi	
 
 # We always want to use the same name for this directory, so that dejagnu
 # can reliably find it.
-target_subdir=${target}
+target_subdir=${target_alias}
 
 if test ! -d ${target_subdir} ; then
   if mkdir ${target_subdir} ; then true
@@ -211,7 +211,8 @@ if test ! -d ${target_subdir} ; then
   fi
 fi
 
-build_subdir=build-${build}
+build_prefix=build-
+build_subdir=${build_prefix}${build_alias}
 
 if test x"${build_alias}" != x"${host}" ; then
   if test ! -d ${build_subdir} ; then

Re: (toplevel patch) Use canonical names for target_subdir, build_subdir.

[Phil Edwards]

On Mon, Jan 27, 2003 at 09:56:29AM -0500, Phil Edwards wrote:
> On Sun, Jan 26, 2003 at 10:44:56AM -0200, Alexandre Oliva wrote:
> > On Jan 26, 2003, Phil Edwards <phil@jaj.com> wrote:
> > > On Fri, Jan 24, 2003 at 02:50:21PM -0200, Alexandre Oliva wrote:
> > >> On Jan 24, 2003, Nathanael Nerode <neroden@twcny.rr.com> wrote:
> > >> 
> > >> > Use the canonical build and target names for build_subdir and target_subdir.
> > >> 
> > >> Not ok.  athlon-linux-gnu is canonicalized to i686-linux-gnu, so we
> > >> can't use the same directories for both of them.  (Consider building a
> > >> compiler on athlon that must run on i686, or on the other way round).
> > 
> > > So, is this going to be reverted or not?  It's destroying the testsuite
> > > results.
> > 
> > Please go ahead and revert it.  It must have gone in by mistake, since
> > it was explicitly rejected.
> 
> Done as below.  Looking over the cvs log, I think Nathanael might have been
> committed this by accident as part of reverting his rda stuff.  That would
> explain why it was committed at the top level and not in the gcc directory.

Criminy.  Now somebody else is complaining about unexpanded macros from
config/acx.m4, even though

    sinclude(config/acx.m4)

is at the top of configure.in.  I'm not seeing this problem, so I can't
help.  So it looks like my reversion will have to be reverted, leaving
us with the original problem again.  Somebody else wanna give it a shot?
(And explain to me why I'm not seeing it?)


Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002