[patch] toplevel configure.in: topsrcdir->srcdir

[patch] toplevel configure.in: topsrcdir->srcdir

[Nathanael Nerode]

This replaces references to ${topsrcdir} with ${srcdir}.  This is correct,
since topsrcdir == srcdir when this is run; it is useful for autoconfiscation, 
because topsrcdir doesn't automatically exist in autoconf scripts, while
srcdir does.

Tested on i686-pc-linux-gnu.

2002-05-23  Nathanael Nerode  <neroden@twcny.rr.com>
	* configure.in: replace ${topsrcdir} with ${srcdir}

*** configure.in.old	Thu May 23 13:50:25 2002
--- configure.in	Thu May 23 13:51:07 2002
***************
*** 1451,1457 ****
    if test x${enable_version_specific_runtime_libs} = xyes; then
      gxx_include_dir='${libsubdir}/include/g++'
    else
!     . ${topsrcdir}/config.if
      gxx_include_dir='${prefix}/include/${libstdcxx_incdir}'
    fi
  else
--- 1451,1457 ----
    if test x${enable_version_specific_runtime_libs} = xyes; then
      gxx_include_dir='${libsubdir}/include/g++'
    else
!     . ${srcdir}/config.if
      gxx_include_dir='${prefix}/include/${libstdcxx_incdir}'
    fi
  else
***************
*** 1472,1478 ****
     esac
  
     # If we're not building GCC, don't discard standard headers.
!    if test -d ${topsrcdir}/gcc; then
       FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -nostdinc'
  
       if test "${build}" != "${host}"; then
--- 1472,1478 ----
     esac
  
     # If we're not building GCC, don't discard standard headers.
!    if test -d ${srcdir}/gcc; then
       FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -nostdinc'
  
       if test "${build}" != "${host}"; then
***************
*** 1518,1524 ****
  # the previously-installed cross compiler, so don't bother to add
  # flags for directories within the install tree of the compiler
  # being built; programs in there won't even run.
! if test "${build}" = "${host}" && test -d ${topsrcdir}/gcc; then
    # Search for pre-installed headers if nothing else fits.
    FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -B$(build_tooldir)/bin/ -B$(build_tooldir)/lib/ -isystem $(build_tooldir)/include'
  fi
--- 1518,1524 ----
  # the previously-installed cross compiler, so don't bother to add
  # flags for directories within the install tree of the compiler
  # being built; programs in there won't even run.
! if test "${build}" = "${host}" && test -d ${srcdir}/gcc; then
    # Search for pre-installed headers if nothing else fits.
    FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -B$(build_tooldir)/bin/ -B$(build_tooldir)/lib/ -isystem $(build_tooldir)/include'
  fi
***************
*** 1532,1538 ****
  
  if test "x${CC_FOR_TARGET+set}" = xset; then
    :
! elif test -d ${topsrcdir}/gcc; then
    CC_FOR_TARGET='$$r/gcc/xgcc -B$$r/gcc/'
  elif test "$host" = "$target"; then
    CC_FOR_TARGET='$(CC)'
--- 1532,1538 ----
  
  if test "x${CC_FOR_TARGET+set}" = xset; then
    :
! elif test -d ${srcdir}/gcc; then
    CC_FOR_TARGET='$$r/gcc/xgcc -B$$r/gcc/'
  elif test "$host" = "$target"; then
    CC_FOR_TARGET='$(CC)'
***************
*** 1548,1554 ****
  
  if test "x${GCJ_FOR_TARGET+set}" = xset; then
    :
! elif test -d ${topsrcdir}/gcc; then
    GCJ_FOR_TARGET='$$r/gcc/gcj -B$$r/gcc/'
  elif test "$host" = "$target"; then
    GCJ_FOR_TARGET='gcj'
--- 1548,1554 ----
  
  if test "x${GCJ_FOR_TARGET+set}" = xset; then
    :
! elif test -d ${srcdir}/gcc; then
    GCJ_FOR_TARGET='$$r/gcc/gcj -B$$r/gcc/'
  elif test "$host" = "$target"; then
    GCJ_FOR_TARGET='gcj'
***************
*** 1562,1568 ****
  
  if test "x${CXX_FOR_TARGET+set}" = xset; then
    :
! elif test -d ${topsrcdir}/gcc; then
    # We add -shared-libgcc to CXX_FOR_TARGET whenever we use xgcc instead
    # of g++ for linking C++ or Java, because g++ has -shared-libgcc by
    # default whereas gcc does not.
--- 1562,1568 ----
  
  if test "x${CXX_FOR_TARGET+set}" = xset; then
    :
! elif test -d ${srcdir}/gcc; then
    # We add -shared-libgcc to CXX_FOR_TARGET whenever we use xgcc instead
    # of g++ for linking C++ or Java, because g++ has -shared-libgcc by
    # default whereas gcc does not.

Re: [patch] toplevel configure.in: topsrcdir->srcdir

[DJ Delorie]

> This replaces references to ${topsrcdir} with ${srcdir}.  This is
> correct,

topsrcdir != srcdir when building multilibs, or any type of cross or
crossed compiler when srcdir==builddir.  Have you tested any of those
configurations?

Re: [patch] toplevel configure.in: topsrcdir->srcdir

[Nathanael Nerode]

On Thu, May 30, 2002 at 02:43:07PM -0400, DJ Delorie wrote:
> 
> > This replaces references to ${topsrcdir} with ${srcdir}.  This is
> > correct,
> 
> topsrcdir != srcdir when building multilibs, or any type of cross or
> crossed compiler when srcdir==builddir.  Have you tested any of those
> configurations?

'topsrcdir' always refers to the top level directory where 'configure'
is located.  When 'configure.in' in the top directory is being run,
srcdir is normally the same directory.  In a subdirectory, srcdir and
topsrcdir differ, but not at the top level.

The situation where topsrcdir!=srcdir at the top level is when a
'srcdir' argument is passed to toplevel configure, and this argument is
*not* the location of toplevel configure.  The build system is not set
up for that situation, and I expect that it breaks already.  In any
case, the changes I make are in fact correct, because otherwise
unintuitively different behavior will result from the current code.

The normal and documented scheme is that 'configure' and 'configure.in'
remain in srcdir, and invoked when the current directory is builddir
by something approximating `${topsrcdir}/configure`.

Using this method, I had no problems with any sort of cross-compiler or 
cross-building.  In each case $topsrcdir *was* the same as $srcdir while
top level configure.in was running. (Modulo the fact that $topsrcdir is
always an absolute directory reference, while $srcdir might be
relative; this isn't a problem because there are no changes of directory
between the setting of 'topsrcdir' and the specific uses I changed.)

I'm not at all sure when "multilibs" are built and when they aren't,
since multilibs are marvelously well undocumented.

Is there something I'm missing, wherein toplevel 'configure' &
'configure.in' could be invoked as a subprocess rather than a top level
process, and accordingly could have been copied into some other
directory (which would become 'topsrcdir'), while still receiving a
'srcdir' argument of the original directory?

I guess I'm saying that I don't see where the problem lies.

--Nathanael

Re: [patch] toplevel configure.in: topsrcdir->srcdir

[DJ Delorie]

> 'topsrcdir' always refers to the top level directory where 'configure'
> is located.  When 'configure.in' in the top directory is being run,
> srcdir is normally the same directory.  In a subdirectory, srcdir and
> topsrcdir differ, but not at the top level.

The case I'm worried about is a src=build cross.  In that case,
configure builds a whole new source tree!  So we must make sure that
it doesn't run the toplevel configure that it may copy to some other
directory, or if it does, that topsrcdir refers to the original
toplevel, not the newly copied one.

I don't think it should do this (it should only copy subdirectories)
but this is one of the cases that often goes unworking for long
periods.

Re: [patch] toplevel configure.in: topsrcdir->srcdir

[DJ Delorie]

> 2002-05-23  Nathanael Nerode  <neroden@twcny.rr.com>
> 	* configure.in: replace ${topsrcdir} with ${srcdir}

Approved and applied.