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

[Nathanael Nerode <neroden at doctormoo dot dyndns dot org>]

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