[DotGNU]HELP: fixing configure.in

[S11001001]

Read the attached text file please; Mozilla was annoying me with 
wrapping, so I did this one in Emacs (and my favorite command, M-q).

--
Stephen Compall
DotGNU `Contributor' -- http://dotgnu.info

There has been another attempt to seize power. So far, the
aristocratic forces have been defeated.
        -- Radio Free OZ

Since I'm not a shell-script junkie, I figured the best thing to do
would be to ask the list.

I have fixed most of pnet so that you can build out-of-tree (that is,
PWD=pnet, cd .., mkdir pnet-build, cd pnet-build, ../pnet/configure,
make, make install). However, one element still remains.

Here is the relevant section of configure.in, as it stands currently in CVS:

dnl Configure libffi and libgc.  We do these manually to avoid
dnl some issues with different versions of autotools, and so that
dnl we can pass specific options to the packages.
if test "x$no_recursion" != "xyes"; then
        if test x$withffi = xyes ; then
                cd "${srcdir}/libffi"
                ./configure --disable-multilib --disable-shared
                cd ../libgc
        else
                cd "${srcdir}/libgc"
        fi
        if test x$withgc = xyes ; then
                ./configure --enable-threads=$THREADS
        fi
fi

Ok, that was fun. Now here are my changes to it, so it will work
out-of-tree:

dnl Configure libffi and libgc.  We do these manually to avoid
dnl some issues with different versions of autotools, and so that
dnl we can pass specific options to the packages.
if test "x$no_recursion" != "xyes"; then
        if test x$withffi = xyes ; then
                if test ! -d libffi ; then
                        mkdir libffi
                fi
                cd "libffi"
                ${srcdir}/libffi/configure --disable-multilib --disable-shared \
                        --host="${host}" --build="${build}" 
--target="${target}" \
                        --disable-fast-install --prefix="${prefix}" \
                        --exec-prefix="${exec_prefix}" --bindir="${bindir}" \
                        --sbindir="${sbindir}" --libexecdir="${libexecdir}" \
                        --datadir="${datadir}" --sysconfdir="${sysconfdir}" \
                        --sharedstatedir="${sharedstatedir}" \
                        --localstatedir="${localstatedir}" --libdir="${libdir}" 
\
                        --includedir="${includedir}" 
--oldincludedir="${oldincludedir}" \
                        --infodir="${infodir}" --mandir="${mandir}" \
                        --srcdir="${srcdir}/libffi"
                cd ..
        fi

        if test x$withgc = xyes ; then
                if test ! -d libgc ; then
                        mkdir libgc
                fi
                cd libgc
                ${srcdir}/libgc/configure --enable-threads=$THREADS 
--host="${host}" \
                --build="${build}" --target="${target}" --disable-fast-install \
                --prefix="${prefix}" \
                --exec-prefix="${exec_prefix}" --bindir="${bindir}" \
                --sbindir="${sbindir}" --libexecdir="${libexecdir}" \
                --datadir="${datadir}" --sysconfdir="${sysconfdir}" \
                --sharedstatedir="${sharedstatedir}" \
                --localstatedir="${localstatedir}" --libdir="${libdir}" \
                --includedir="${includedir}" --oldincludedir="${oldincludedir}" 
\
                --infodir="${infodir}" --mandir="${mandir}" \
                --srcdir="${srcdir}/libgc"
        fi
fi

Now the important parts aren't all the extra options (they are
designed so that when you customize ./configure for pnet, it will pass
along the customization to libffi and libgc), they are wherever you
see `${srcdir}'.

Rhys said:

Patch applied 4 July 2002, for everything except the changes to
configure.in.  It broke the build in "normal in-tree" builds.

I think there is a relative path issue: ${srcdir} is relative to the
main build directory, and so it points at the wrong place after the
"cd libffi" and "cd libgc" lines.

ENDQUOTE

So even though I realized what he meant (several mins afterwards), I
didn't pursue it any further, because I don't know how to fix this
intelligently.

See, when I tested the build, I used the path (that is, srcdir
variable was set to) "~/ide/dotgnu/pnet". So when it ran configure,
say, in libffi directory, bash expanded it to
"~/ide/dotgnu/pnet/libffi/configure". So all well and dandy.

However, when you are doing what most people (unfortunately) do, that
is, ./configure from the source tree, [I believe] your ${srcdir}
variable would just get set to ".". So when I change into libffi,
${srcdir} has automatically "changed" to reflect this directory
change. So I am trying to do "./libffi/configure" from the pnet/libffi
directory, which is bad, instead of "./configure", which is good (as
it seems to work well enough in public CVS).

This problem expands further when doing an out-of-tree build with a
relative path for your configure invocation, because, given the above
example with a pnet-build directory at the same level as the pnet
directory, you would be invoking "../pnet/libffi/configure", even
though you should do "../../pnet/libffi/configure".

So finally, the problem is to figure out which method you should use
for creating a configure invocation (as well as something to pass to
--srcdir=, IIRC):

In abs path cases, you would do "${srcdir}/libffi/configure"

In relative path cases, you would do "../${srcdir}/libffi/configure"
(regardless of your awkward, but workable, end result in same-tree
instances, ".././libffi/configure"

I WANT CODE!