Problem building CVS Guile with automake 1.6.1

Problem building CVS Guile with automake 1.6.1

[Matthias Koeppe]

Guile's `guile-aclocal.sh' script fails with automake 1.6.1.  Here is
the relevant part:

 |  # copy all installed aclocal files into $temp
 |  cp `aclocal --print-ac-dir`/*.m4 $temp
 |  
 |  # remove the .m4 files installed by Guile from $temp, so they don't
 |  # cause conflicts
 |  rm -f ${temp}/guile.m4 ${temp}/qthreads.m4
 |  
 |  aclocal --acdir=$temp -I .

As far as I understand it, this fails with automake 1.6.1 because the
"aclocal" library location is versioned with the automake API version.
On my system, the location is 

   /localapp/imosoft/sparcv9-sun-solaris2.7/share/aclocal-1.6

but 

 aclocal --print-ac-dir 
  ==> /localapp/imosoft/sparcv9-sun-solaris2.7/share/aclocal

which happens to point to an old (1.4) installation of the aclocal
library.

When aclocal is invoked with --acdir set to a copy of this library, 
automake fails with these messages:

configure.in:28: your implementation of AM_INIT_AUTOMAKE comes from an
configure.in:28: old Automake version.  You should recreate aclocal.m4
configure.in:28: with aclocal and run automake again.

Clearly something needs to be fixed.  Is it aclocal (to return the
versioned "aclocal" directory) or Guile?

-- 
Matthias Köppe -- http://www.math.uni-magdeburg.de/~mkoeppe

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Problem building CVS Guile with automake 1.6.1

[Alexandre Duret-Lutz]

>>> "Matthias" == Matthias Koeppe <mkoeppe@saturn.Math.Uni-Magdeburg.De> writes:

 Matthias> Guile's `guile-aclocal.sh' script fails with automake
 Matthias> 1.6.1.  Here is the relevant part:

 >> # copy all installed aclocal files into $temp
 >> cp `aclocal --print-ac-dir`/*.m4 $temp
 >> 
 >> # remove the .m4 files installed by Guile from $temp, so they don't
 >> # cause conflicts
 >> rm -f ${temp}/guile.m4 ${temp}/qthreads.m4
 >> 
 >> aclocal --acdir=$temp -I .

This is a work-around makes sense up to Automake 1.4.
It still works with 1.5.
It breaks with recent versions.

aclocal from Automake 1.4 chokes when a -I supplied macro
override a /usr/share/aclocal/ macro, hence your script.

Starting with Automake 1.5, a macro supplied with -I will
override any macro installed in /usr/share/aclocal/, so
you simply have to run

  aclocal -I .

(no cp, rm, or --acdir)

 Matthias> As far as I understand it, this fails with automake
 Matthias> 1.6.1 because the "aclocal" library location is
 Matthias> versioned with the automake API version.  

Starting with Automake 1.6, there are TWO places:

$datadir/aclocal-1.6/
  The directory where Automake puts its internal macros
  (AM_INIT_AUTOMAKE and the like).  This needs to be versioned.

$datadir/aclocal/
  This is the directory where third-party packages are expected
  to put their macros.  This is not versioned, since these
  macros are really independent of Automake.

 Matthias> On my system, the location is

 Matthias> /localapp/imosoft/sparcv9-sun-solaris2.7/share/aclocal-1.6

This is Automake's own macro repository.  The user should not
have to fiddle with it.

 Matthias> but 

 Matthias> aclocal --print-ac-dir 
 Matthias> ==> /localapp/imosoft/sparcv9-sun-solaris2.7/share/aclocal

This prints the directory when third-party packages are expected
to install their macros.

 Matthias> which happens to point to an old (1.4) installation of the aclocal
 Matthias> library.

If you haven't uninstalled Automake 1.4/1.5, their files are
still here.  This is harmless: the macros found in the versioned
directory have priority.

 Matthias> When aclocal is invoked with --acdir set to a copy of this library, 
 Matthias> automake fails with these messages:

--acdir overrides both the private (versioned) and public
(unversioned) aclocal directories, hence the failure.  (This
switch is needed in Automake's testsuite which has to run
aclocal before the macros are installed.)

[...]

-- 
Alexandre Duret-Lutz


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Problem building CVS Guile with automake 1.6.1

[Matthias Koeppe]

Alexandre Duret-Lutz <duret_g@lrde.epita.fr> writes:

>>>> "Matthias" == Matthias Koeppe <mkoeppe@saturn.Math.Uni-Magdeburg.De> writes:
>
>  Matthias> Guile's `guile-aclocal.sh' script fails with automake
>  Matthias> 1.6.1.  Here is the relevant part:
>
>  >> # copy all installed aclocal files into $temp
>  >> cp `aclocal --print-ac-dir`/*.m4 $temp
>  >> 
>  >> # remove the .m4 files installed by Guile from $temp, so they don't
>  >> # cause conflicts
>  >> rm -f ${temp}/guile.m4 ${temp}/qthreads.m4
>  >> 
>  >> aclocal --acdir=$temp -I .
>
> This is a work-around makes sense up to Automake 1.4.
> It still works with 1.5.
> It breaks with recent versions.
>
> aclocal from Automake 1.4 chokes when a -I supplied macro
> override a /usr/share/aclocal/ macro, hence your script.
>
> Starting with Automake 1.5, a macro supplied with -I will
> override any macro installed in /usr/share/aclocal/, so
> you simply have to run
>
>   aclocal -I .
>
> (no cp, rm, or --acdir)
>
> [...]

Alexandre, thank you very much for the detailed explanation.  

Dear Guile maintainers: I have prepared the patch below, which checks
for Automake 1.4, for which the work-around is still used; for newer
automake, aclocal is called directly.  (Alternatively, one could
require Automake 1.5 for hacking Guile and get rid of the work-around
altogether.)

-- Matthias

--- guile-aclocal.sh.~1.1~	Thu Jun  1 17:10:50 2000
+++ guile-aclocal.sh	Fri Apr 26 14:46:04 2002
@@ -1,19 +1,25 @@
-#!/bin/sh
+#!/bin/sh -x
 
-temp=/tmp/guile-aclocal.$$
-trap "rm -rf $temp" 0 1 2 15
+if aclocal --version | head -1 | grep '1\.4' > /dev/null ; then
+    ## Workaround for Automake < 1.5:
+    temp=/tmp/guile-aclocal.$$
+    trap "rm -rf $temp" 0 1 2 15
 
-mkdir $temp
-[ -d $temp ] || {
-  echo "guile-aclocal.sh: cannot create temp directory"
-  exit 1
-}
+    mkdir $temp
+    [ -d $temp ] || {
+	echo "guile-aclocal.sh: cannot create temp directory"
+	exit 1
+    }
 
-# copy all installed aclocal files into $temp
-cp `aclocal --print-ac-dir`/*.m4 $temp
+    # copy all installed aclocal files into $temp
+    cp `aclocal --print-ac-dir`/*.m4 $temp
 
-# remove the .m4 files installed by Guile from $temp, so they don't
-# cause conflicts
-rm -f ${temp}/guile.m4 ${temp}/qthreads.m4
+    # remove the .m4 files installed by Guile from $temp, so they don't
+    # cause conflicts
+    rm -f ${temp}/guile.m4 ${temp}/qthreads.m4
 
-aclocal --acdir=$temp -I .
+    aclocal --acdir=$temp -I .
+else
+    ## Automake >= 1.5 works
+    aclocal -I .
+fi

-- 
Matthias Köppe -- http://www.math.uni-magdeburg.de/~mkoeppe

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Problem building CVS Guile with automake 1.6.1

[Marius Vollmer]

Matthias Koeppe <mkoeppe@mail.Math.Uni-Magdeburg.De> writes:

> Dear Guile maintainers: I have prepared the patch below, which checks
> for Automake 1.4, for which the work-around is still used; for newer
> automake, aclocal is called directly.  (Alternatively, one could
> require Automake 1.5 for hacking Guile and get rid of the work-around
> altogether.)

Thanks!  (We've known about this issue already, and I have a fix ready
waiting to be comitted...)

We are simply requiring automake 1.5 and put all Guile local macros
into guile-config/.  Therefore, we need to run aclocal as

    aclocal -I guile-config/

and also rig the top Makefile.am to pass "-I guile-config" to aclocal
when automatically regenerating aclocal.m4.

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Problem building CVS Guile with automake 1.6.1

[Thien-Thi Nguyen]

   From: Matthias Koeppe <mkoeppe@mail.Math.Uni-Magdeburg.De>
   Date: Fri, 26 Apr 2002 16:37:29 +0200

   Dear Guile maintainers: I have prepared the patch below, which checks
   for Automake 1.4, for which the work-around is still used; for newer
   automake, aclocal is called directly.  (Alternatively, one could
   require Automake 1.5 for hacking Guile and get rid of the work-around
   altogether.)

yeah, i think we're going w/ automake 1.5 at the moment (as encoded by
guile-core/Makefile.am AUTOMAKE_OPTIONS) to address the include-file
bug.  i notice 1.6 has been released since early march.  if HACKING is
to believed, we should soon migrate to 1.6, so it would be nice to get a
patch to make everything work w/ 1.6.

[cc trimmed.]

(btw, i thought you had guile write privs?)

thi

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel