On 17/10/2017 13:45, Mathieu Lirzin wrote:
>>> 1 file changed, 11 insertions(+), 1 deletion(-)
> I haven't tested this, and I am not a Libtool expert so I trust your
> analysis.
>
> What do you think of adding a test ensuring that ltmain.sh is not
> required when no Libtool macro is found?
>
>
On 31/10/2016 13:30, Paolo Bonzini wrote:
> If Automake does not see LT_SUPPORTED_TAG, it assumes an old libtool
> that does not know about AC_REQUIRE_AUX_FILE. However, if the program
> does not use Libtool's configure.ac macros this check gets a
> false positive. Do not requi
that are not stone-age are already covered by LT_SUPPORTED_TAG
and _LT_AC_TAGCONFIG, but add AC_PROG_LIBTOOL just in case for Libtool
up to 1.4.
2016-10-31 Paolo Bonzini <bonz...@gnu.org>
* bin/automake.in ($libtool_bundled): New.
(handle_libtool): Do not require libtool
Il 31/12/2012 10:05, Stefano Lattarini ha scritto:
On 12/30/2012 07:08 PM, Paolo Bonzini wrote:
Il 30/12/2012 11:23, Stefano Lattarini ha scritto:
+AC_DEFUN([AM_CONFIG_HEADER],
+[AC_FATAL(['$0': this macro is obsolete.
+You should use the 'AC][_CONFIG_HEADERS' macro instead
Il 31/12/2012 11:32, Stefano Lattarini ha scritto:
It is indeed possible that the real reason that pushed me to remove
AM_CONFIG_HEADER was the fact that I got caught in a cleanup frenzy
when I was removing other (real) cruft. You are starting to partly
convince me of that.
These patches are
Il 30/12/2012 11:23, Stefano Lattarini ha scritto:
+AC_DEFUN([AM_CONFIG_HEADER],
+[AC_FATAL(['$0': this macro is obsolete.
+You should use the 'AC][_CONFIG_HEADERS' macro instead.])])
+
What's the point in doing this instead of
m4_defun([AM_CONFIG_HEADER], [AC_CONFIG_HEADERS])
or
On 09/20/2011 12:51 PM, Stefano Lattarini wrote:
Yes (and that's on purpose: ACLOCAL_PATH is typically used by a user
which has newer versions of libraries installed, so they need their
directories to override everything).
Yes, this might be desirable. But then, for consistency sake,
On 09/20/2011 02:09 PM, Stefano Lattarini wrote:
Yeah, I think the problem is that in the normal search path (from
`aclocal -I /foo -I /bar'):
1. `/foo'
2. `/bar'
3. ACDIR-APIVERSION
4. ACDIR
The directories from dirlist and ACLOCAL_PATH should go after (3),
rather than
On 09/19/2011 06:05 PM, Stefano Lattarini wrote:
I'll push the attached patch in 72 hours if there is no review by then.
Paolo, since it's you who have written the previous version of this patch,
from which I've drawn heavily, are you ok to be listed as the main author
in the ChangeLog entry,
On 09/19/2011 06:05 PM, Stefano Lattarini wrote:
Resurrecting the old thread Add ACLOCAL_PATH to aclocal; references:
http://lists.gnu.org/archive/html/automake-patches/2010-11/msg00089.html
http://thread.gmane.org/gmane.comp.sysutils.automake.patches/4972
I really want the ACLOCAL_PATH
On 11/14/2010 05:46 PM, Ralf Wildenhues wrote:
Hi Paolo,
* Paolo Bonzini wrote on Tue, Nov 09, 2010 at 08:14:39PM CET:
This patch simplifies the overly complicated rules for ACLOCAL_PATH
vs. @automake_includes and @system_includes, by stating that
ACLOCAL_PATH will override even
and
system directories to local and global, as discussed in the v1
thread as well.
Paolo Bonzini (3):
aclocal: handle ACLOCAL_PATH environment variable
aclocal: remove @automake_includes
aclocal: rename search path variables
ChangeLog | 41 +++
NEWS
/aclocal.in| 14 +++---
9 files changed, 195 insertions(+), 8 deletions(-)
create mode 100755 tests/acloca24.test
create mode 100755 tests/acloca25.test
diff --git a/ChangeLog b/ChangeLog
index 5fff04a..fa43c14 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,17 @@
+2010-11-09 Paolo Bonzini
/acloca25.test |7 +--
5 files changed, 41 insertions(+), 27 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index fa43c14..ede73dc 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,20 @@
2010-11-09 Paolo Bonzini bonz...@gnu.org
+ aclocal: remove @automake_includes.
+ * NEWS
changed, 37 insertions(+), 25 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index ede73dc..b3ec1fb 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,17 @@
2010-11-09 Paolo Bonzini bonz...@gnu.org
+ aclocal: rename search path variables.
+ * aclocal.in (user_includes): Rename
Hi all, this patch provides a fourth scheme of adding directories to
the search path. It is a simple colon-separated list of directories
(without globbing).
It is useful when you're using a global installation of Automake but
you want to add directories from your account as well to the search
On 11/03/2010 04:24 PM, Stefano Lattarini wrote:
+ # Add any directory listed in the `ACLOCAL_PATH' environment
+ # variable.
+ if (defined $ENV{ACLOCAL_PATH})
+{
+ foreach my $dir (split /:/, $ENV{ACLOCAL_PATH})
Shouldn't we use `...@path_separator@' here instead of `:', for better
Ok for trunk and 4.3, but please also handle enable_static in the
same way. The patch is preapproved with this change, but please repost
it so that it can also go in Automake (I'm CCing Ralf and
automake-patches@gnu.org for this).
Paolo
PING... (or just give me commit access so I can do it myself).
http://permalink.gmane.org/gmane.comp.sysutils.automake.patches/2731
Paolo
Ok, here's the patch I sent a month ago together with new
testcases.
I also found a little opportunity for refactoring.
Paolo
2007-03-12 Paolo Bonzini [EMAIL PROTECTED]
* automake.in (output_texinfo_build_rules): Add COND parameter.
Emit INFO_DEPS and TEXINFOS
I'd appreciate it if this could go on the 1.9.x branch as well as
mainline.
I think Alexandre doesn't plan another 1.9.x release.
Distro makers might take the patch, though. I support Geoff's request.
Paolo
21 matches
Mail list logo
