This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: in src configuration broken on 8/4 or 8/5


In article <20030828164142.GA21802@disaster.jaj.com>,
Phil Edwards<phil@jaj.com> writes:

>> Please fix if you were responsible.
>         Convert to new autotools.

> I thought the new tools handled this case themselves now, but it seems we
> still need to do some hand-holding.

OK, I volunteered to help fix such upgrade problem (sorry I didn't
notice it was related ;-).  I think I found it.

[Abstract from cvs diff -D 'Aug 1' -D 'Aug 5' libstdc++-v3/acinclude.m4]
<   # When building with srcdir == objdir, links to the source files will
<   # be created in directories within the target_subdir.  We have to
<   # adjust toplevel_srcdir accordingly, so that configure finds
<   # install-sh and other auxiliary files that live in the top-level
<   # source directory.
<   if test "${srcdir}" = "."; then
<     if test -z "${with_target_subdir}"; then
<       toprel=".."
<     else
<       if test "${with_target_subdir}" != "."; then
<         toprel="${with_multisrctop}../.."
<       else
<         toprel="${with_multisrctop}.."
<       fi
<     fi
---
>   # Sets up multi_basedir, which is srcdir/.. plus the usual
>   # "multi_source_toprel_bottom_adjust" lunacy as needed.
>   AM_ENABLE_MULTILIB(, ..)
> 
>   # The generated code is exactly the same, except that automake's looks in
>   # ".. $srcdir/.." and autoconf's looks in multi_basedir.  Apparently other
>   # things are triggered on the presence of the two ...AUX_DIR[S], but I don't
>   # know what they are or what the other differences might be (and they keep
>   # changing anyhow).
>   #
>   # Looking in multi_basedir seems smarter, so actually execute that branch.
>   if false; then
>     # this is for automake
>     AC_CONFIG_AUX_DIR(..)

Then notice how we no longer use toprel to "properly" compute toplevel_srcdir:

; ccvs diff -D 'Aug 1' -D 'Aug 5' libstdc++-v3/acinclude.m4|grep toplevel_srcdir
< dnl Initialize basic configure bits, set toplevel_srcdir for Makefiles.
<   # adjust toplevel_srcdir accordingly, so that configure finds
<   toplevel_srcdir=\${top_srcdir}/$toprel
<   AC_SUBST(toplevel_srcdir)
> dnl  toplevel_srcdir      (absolute path)
>   toplevel_srcdir=${glibcxx_srcdir}/..
>   AC_SUBST(toplevel_srcdir)

Since it is still true that .. is correct for obj configure and
../.. is correct for src configure, any patch which makes
toplevel_srcdir unconditionally .. was wrong (but quite understandable
since we continue to allow ten^6 ways to configure a tree)

Phil, do we want to add back in the old hack in some form?  Or is
there suppose to be a way to do this properly in the new
automake/autoconf?  We may be defeated by use of older auto-tools at
top-level.

Regards,
Loren


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]