libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why doesn't ...


From: Alexandre Duret-Lutz
Subject: Re: Why doesn't ...
Date: Tue, 03 Feb 2004 23:52:25 +0100
User-agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux)

>>> "Scott" == Scott James Remnant <address@hidden> writes:

 Scott> On Thu, 2004-02-05 at 03:40, name wrote:
 >> Why doesn't installation copy libtool.m4 to aclocal?
 >> 
 Scott> Assuming you are talking about CVS HEAD (libtool 1.5a, future 1.6
 Scott> release) this is because libtoolize now copies libtool.m4 from its own
 Scott> data directory into your macro directory.
[...]
 Scott> This is consistent with "The Future of `aclocal'" as outlined in the
 Scott> Automake manual chapter of the same title.

I know you are just explaining the libtoolize behavior with
this sentence, but I fear that some people might read it as a
justification for not putting things into /usr/share/aclocal/.

I'm installing the following patch on automake HEAD and
branch-1-8 to make things clearer.

Changing libtoolize to install libtool.m4 locally is a great
step, but it seems it would work as well if libtool.m4 was taken
from /usr/share/aclocal/.  Moving it away might be too harsh for
users.  AFAICT the real advantage with putting libtool.m4 out of
the way, is that it helps ./bootstrap to cope with the
shortcomings of the current aclocal implementation...

BTW, the conditionally defined AC_PROG_EGREP debacle (replace
AC_PROG_EGREP by any Autoconf macro) should not exist with the
replacement machinery Akim plotted, since AC_DEFUNs would be
traced instead of being hastily grepped.  Actually I think this
part of the plot could be implemented now (i.e., in am-1.9)
easily.  I'll try to look at it.

 Scott> The great advantage of this is that it ensures that
 Scott> libtool.m4 and ltmain.sh are matched versions, running
 Scott> libtoolize and forgetting to run aclocal, or the
 Scott> reverse, used to be the source of many developer's woes
 Scott> in the past.

Good point.  I wonder if you'll have more complaints about
mismatched versions or about missing libtool.m4 (not meaning to
be flip, I don't read bug-libtool so I don't know how frequent
the version mismatch problem is, but the missing libtool.m4
problem seems to be quite popular already before the release).

Another way to ensure matching versions would be to turn
ltmain.sh into an m4 macro.  (I wouldn't have dared suggesting
that if someone didn't already.  I think it was Gary.  Please
move the bazooka over him :))


2004-02-03  Alexandre Duret-Lutz  <address@hidden>

        * doc/automake.texi (Future of aclocal): Make clearer that
        it's ok to install macros into /usr/share/aclocal/.

Index: doc/automake.texi
===================================================================
RCS file: /cvs/automake/automake/doc/automake.texi,v
retrieving revision 1.27
diff -u -r1.27 automake.texi
--- doc/automake.texi   1 Feb 2004 16:28:50 -0000       1.27
+++ doc/automake.texi   3 Feb 2004 22:05:44 -0000
@@ -2088,8 +2088,9 @@
 
 The new implementation will probably be done slightly differently.
 For instance it could enforce the @file{m4/}-style layout discussed in
address@hidden Macros}, and take care of copying (or even updating)
-third-party macro into this directory.
address@hidden Macros}, and take care of copying (and even updating)
+third-party macros from @file{/usr/share/aclocal/} into the local
address@hidden/} directory.
 
 We have no idea when and how this will happen.  This has been
 discussed several times in the past, but someone still has to commit
@@ -2115,6 +2116,13 @@
 should simplify its logic a lot (less things to maintain, yum!), it's
 even likely you will not need the script anymore, and more to the point
 you will not call @command{aclocal} directly anymore.
+
+For the time being, third-party packages should continue to install
+public macros into @code{/usr/share/aclocal/}.  If @command{aclocal}
+is replaced by another tool it might make sense to rename the
+directory, but supporting @code{/usr/share/aclocal/} for backward
+compatibility should be really easy provided all macros are properly
+written (@pxref{Extending aclocal}).
 
 
 @node Top level
-- 
Alexandre Duret-Lutz





reply via email to

[Prev in Thread] Current Thread [Next in Thread]