This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: tips for configuring in the source directory?
- To: Benjamin Kosnik <bkoz at redhat dot com>
- Subject: Re: tips for configuring in the source directory?
- From: Alexandre Oliva <oliva at lsd dot ic dot unicamp dot br>
- Date: 28 Nov 2000 21:53:10 -0200
- Cc: autoconf at gnu dot org, gcc at gcc dot gnu dot org
- References: <Pine.SOL.3.91.1001128152159.27727A@cse.cygnus.com>
On Nov 28, 2000, Benjamin Kosnik <bkoz@redhat.com> wrote:
> There has recently been some noise on the gcc lists about making gcc
> work for in-source configures and builds. As part of that, I'd like
> to try and get libstdc++-v3 to work with in-source configuring. It
> uses autoconf/automake/libtool.
It also uses some multilib magic that are characteristic of the
so-called Cygnus tree. Unfortunately, that's the piece that's
responsible for the soft-linking madness. Part of it is in
`$(CONFIGURE_TARGET_MODULES):' in Makefile.in, part of it is in
config-ml.in, where the process appears to be documented (and I only
repeat it here because I typed most of what's below before noticing it
was already there :-)
The reason why the link is created is that, in case the library is
configured for both host and target (as is the case of zlib, just to
point out an example), `configure' would refuse to run for the target,
within <targetname>/[multilibdir/]zlib, because the source tree would
have already been configured for the host. autoconf won't let the
configure script run for a separate build tree if the source tree is
already configured. The rationale is that, if it let the configure
and build proceed, all sorts of problems would follow because of VPATH
pointing to files in the source tree (which is also the old build
tree) and causing make to find build files in the source tree, so it
would not build them again for the target.
The problem with libsupc++ is that it sets AC_CONFIG_AUX_DIR as `..',
which is fine when objdir != srcdir, because `..' is relative to
`srcdir', but not when the global objdir == srcdir, because then the
soft-linking magic in config-ml.in takes place, and then srcdir == .
The bad news is that I can't think of an easy solution for the
problem. We could just omit AC_CONFIG_AUX_DIR from libsupc++ and let
autoconf's default searching in `$srcdir $srcdir/.. $srcdir/../..' to
take place, but this would fail to find install-sh in case libsupc++
is configured in <targetdir>/libstdc++-v3/libsupc++, three levels
deeper than install-sh.
My best bet would be:
AC_CONFIG_AUX_DIR(`if test "x${srcdir}" = x.; then
if test "x${with_target_subdir}" != x.; then
echo ${with_multisrctop}../../..
else
echo ${with_multisrctop}../..
fi
else
echo ${srcdir}/../..
fi`)
(note that this is similar to the sample snippet in config-ml.in about
how to add it to configure.in, but there's one additional `..' in each
set, because libsupc++ is a sub-directory of libstdc++-v3)
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me