http://mail.gnu.org/archive/html/autoconf-patches/2003-11/msg00075.html
fixes the longstading (dates back to the beginning of the CVS
repository) failure to use the third argument of AU_DEFUN.
Maybe given the problems with 2.58 it would be good to distribute
Automake 1.8 and Autoconf 2.60
Here's it for you, a bug in the missing script.
Paolo
---BeginMessage---
There was an error when I ran make install-strip.
Thanks for gnuplot. The demos are working just fine.
I am running gnuplot on HP-UX B.11.23 U ia64
Dale Holt
Colorado Springs
Making install in docs
Ralf Wildenhues wrote:
Hello Brooks,
* Brooks Moses wrote on Tue, Nov 06, 2007 at 11:19:21PM CET:
This resulted in the error quoted in the subject line, automake does not
support info_TEXINFOS being defined conditionally, followed by an Internal
Error.
Hmm, something got stuck there:
Bruno Haible wrote:
Paolo Bonzini wrote:
But the compiler does not know that fstrcmp is called millions of time and
that this piece of code needs to be optimized for speed rather than for
space.
If doing profile-directed optimization, it does know.
However, it is impractical: I never used
I get errors running ./configure. I guess, this is, because of a problem
with the quotation. Doing a simple:
AC_SUBST([DESKTOP_DATA_RULE], [
target: requirements
@list=...
])
DESKTOP_DATA_RULE=AS_ESCAPE([
...
])
AC_SUBST([DESKTOP_DATA_RULE])
should work.
Paolo
On 12/13/2009 10:31 AM, Jim Meyering wrote:
-# Use this to make sure we don't run these programs when building
-# from a virgin tgz file, below.
-null_AM_MAKEFLAGS = \
- ACLOCAL=false \
- AUTOCONF=false \
- AUTOMAKE=false \
- AUTOHEADER=false \
- MAKEINFO=false
This rule could actually be
to make the PIC test
overridable.
The patch is quite risky though.
Paolo
Paolo Bonzini (2):
split -Wl test
extract static flag detection
hmm, looking into the patch I don't see how this lets me
replace -fPIC with -fpic. Maybe I am missing something?
It is not complete, hence here
While looking around at the most common shell idioms in otherwise
simple configure.ac files, I found a very common one:
AC_ARG_ENABLE([something], [--enable-somethingxyz],,
[enable_something=no])
AM_CONDITIONAL([SOMETHING, [test $enable_something != no])
What would you think about one
On 11/21/2011 09:56 PM, Stefano Lattarini wrote:
Here is my tentative plan to act on the proposal:
1. We start requiring GNU make in an experimental automake 2.0
development line (which might, and will, break whathever
backward-compatibility gets in its way).
2. Concurrently,
On 11/22/2011 04:35 PM, Stefano Lattarini wrote:
1. Automake 2 turns out to be a failure, it gets abandoned, and
Automake 1 becomes again the center of all our developement
efforts. No problem for you, since you're still using this older
automake.
2. Automake 2 is a success,
On 11/24/2011 04:51 PM, Richard Stallman wrote:
I agree the reason becomes less compelling as more capable systems
become more commonplace, but I do not agree ancient RISC boxes are no
longer an interesting target for current NTP builds.
The machine I use (and many of us, too)
Il 21/08/2012 12:10, Stefano Lattarini ha scritto:
(AC_SUBST): Define AM_VARTYPOS_WHITELIST to LIBFFI_EXECUTABLE_LDFLAGS
RELOC_LDFLAGS. This is required because Automake-NG is stricter than
mainline Automake in its make runtime checks on possible typos in
variables like 'foo_SOURCES' and
Il 21/08/2012 14:44, Stefano Lattarini ha scritto:
But there is an important difference: Automake-NG is *not* the next
version of Automake, it is the Next Generation: it's not meant to
be merged into the Automake code base, nor to supersede Automake,
because the two projects have different
Il 21/08/2012 16:32, Stefano Lattarini ha scritto:
Bottom line is: we want to make it clear that Automake-NG is something
different from Automake -- albeit mostly compatible, deliberately, and
with very, very similar design and API; and that a transition between
the two won't be seamless --
Il 21/08/2012 16:53, Diego Elio Pettenò ha scritto:
do you think the transition would have been less painful (I really
hope the answer is yes, of course).
From a distribution point of view... it wouldn't have been any less
painful. It would have meant we'd have even more packages using
Il 21/08/2012 17:42, Stefano Lattarini ha scritto:
Not sed, no (maybe you can try it to see how the conversion goes from someone
not involved in Automake-NG as I am?). But grep, coreutils, m4 (1.4.x
branch),
bison, dejagnu, parted and autoconf has already been successfully converted:
Ok. So the question I'd like you to ask yourself are:
* Why does it make sense to request manual declaration of 'SUFFIXES'?
* Does it make sense to do so in Automake, too?
And another question:
* Alternatively, could Automake-NG suggest converting suffix rules to
pattern rules so that the
Il 21/08/2012 18:01, Paolo Bonzini ha scritto:
Ok. So the question I'd like you to ask yourself are:
* Why does it make sense to request manual declaration of 'SUFFIXES'?
* Does it make sense to do so in Automake, too?
And another question:
* Alternatively, could Automake-NG suggest
Il 21/08/2012 18:30, Ralf Corsepius ha scritto:
Yes, that's correct. PR and advertisement is what lacked in the early
Autoconf 2.5x releases.
Really? That's not how I recall the situation. I recall people turning
away from autoconf in disgust because of the numerous incompatiblities
and
Il 21/08/2012 19:14, Stefano Lattarini ha scritto:
* warn for unknown *_XYZFLAGS variables
I'm still unconvinced it would be a good idea to introduce this
incompatibility in Automake just for the sake of simplifying
transition to Automake-NG, sorry.
* warn for treating _SOURCES entries
On Tue, Aug 21, 2012 at 9:10 PM, Stefano Lattarini
stefano.lattar...@gmail.com wrote:
On 08/21/2012 08:51 PM, Paolo Bonzini wrote:
Il 21/08/2012 19:14, Stefano Lattarini ha scritto:
* warn for unknown *_XYZFLAGS variables
I'm still unconvinced it would be a good idea to introduce
Il 21/08/2012 20:58, Bob Friesenhahn ha scritto:
Because all of us have forgotten to drop the 'CC:' to that list (where
the discussion originated from) at a proper time :-(
If it had been held only on the automake list then there would be less
harm to the free software world
Which harm are
So I took a closer look at the whitelisting problem that was reported
in GNU Smalltalk.
The piece of code that was removed in Automake-NG is:
foreach my $primary ('SOURCES', 'LIBADD', 'LDADD', 'LDFLAGS', 'DEPENDENCIES')
{
foreach my $var (variables $primary)
{
my
On Wed, Aug 22, 2012 at 5:12 PM, Stefano Lattarini
stefano.lattar...@gmail.com wrote:
On 08/21/2012 06:03 PM, Paolo Bonzini wrote:
Looking at GNU Smalltalk, I see:
* warn for INCLUDES (vs. AM_CPPFLAGS)
Turns out this has already been done for ages (at least since 2003).
I'll just remove
Il 22/08/2012 23:52, Stefano Lattarini ha scritto:
I'd much rather a mandatory noisy warning period before a feature is
completely removed.
This would require a new category of warnings that are are unconditionally
show, regardless of strictness or any -Wnone option. As usual, patches
Il 23/08/2012 10:36, Stefano Lattarini ha scritto:
On 08/22/2012 12:32 PM, Paolo Bonzini wrote:
How would you diagnose a typo in here at Automake runtime?
bin_PROGRAMS = $(call user-func,args)
bin_PROGRAMS += $(if $(ON-CYGWIN),baz)
ifdef ON-CYGWIN
# Oops, this was meant
@@
+2012-12-29 Stefano Lattarini stefano.lattar...@gnu.org (tiny change)
+
+ build: use AC_CONFIG_HEADERS, not AM_CONFIG_HEADER
+ * configure.ac: Here. The latter has been removed in Automake 1.13.
+
2012-12-21 Paolo Bonzini bonz...@gnu.org
* configure.ac: Bump
Il 29/12/2012 21:43, Stefano Lattarini ha scritto:
On 12/29/2012 08:46 PM, Paolo Bonzini wrote:
Il 29/12/2012 17:32, Stefano Lattarini ha scritto:
* configure.ac: Here. The latter has been removed in Automake 1.13.
Is there any reason for this,
Avoiding to keep too much cruft around
Il 11/01/2013 11:28, Stefano Lattarini ha scritto:
* snprintfv/configure.ac: Here. Not only that substitution was useless,
but it was causing runtime warnings with Automake 1.13, and, since
support for $(INCLUDES) is bound to disappear in Automake 1.14 (in favour
of $(AM_CPPFLAGS)), it will
Il 26/09/2013 18:16, Diab Jerius ha scritto:
# The `:;' works around a Bash 3.2 bug when the output is not writable.
%D%/package.m4: $(top_srcdir)/configure.ac
:;{ \
echo '# Signature of the current package.' \
echo 'm4_define([AT_PACKAGE_NAME],' \
echo '
Il 20/11/2013 09:47, Torbjorn Granlund ha scritto:
Christian Rössel christian.roes...@gmx.de writes:
assuming that you are using libtool, just configure twice, with
--enable-static --disable-shared' and '--disable-static
--enable-shared' respectively. Maybe this is not the solution you
Il 21/08/2012 14:44, Stefano Lattarini ha scritto:
But there is an important difference: Automake-NG is *not* the next
version of Automake, it is the Next Generation: it's not meant to
be merged into the Automake code base, nor to supersede Automake,
because the two projects have different
Il 21/08/2012 16:32, Stefano Lattarini ha scritto:
Bottom line is: we want to make it clear that Automake-NG is something
different from Automake -- albeit mostly compatible, deliberately, and
with very, very similar design and API; and that a transition between
the two won't be seamless --
Il 12/08/2012 23:20, Stefano Lattarini ha scritto:
The API to specify the formats of distribution tarballs has been changed
completely, in a BACKWARD-INCOMPATIBLE way.
Instead of using the various 'dist-*' automake options, the developer is
now expected to specify the default formats of its
Il 21/08/2012 19:14, Stefano Lattarini ha scritto:
* warn for unknown *_XYZFLAGS variables
I'm still unconvinced it would be a good idea to introduce this
incompatibility in Automake just for the sake of simplifying
transition to Automake-NG, sorry.
* warn for treating _SOURCES entries
Il 21/08/2012 20:58, Bob Friesenhahn ha scritto:
Because all of us have forgotten to drop the 'CC:' to that list (where
the discussion originated from) at a proper time :-(
If it had been held only on the automake list then there would be less
harm to the free software world
Which harm are
We want AUTOMAKE_OPTIONS in Makefile.in to be the combination of
configure.ac and Makefile.am options. Define a new variable owner
for this, because we need to override the Makefile.am value
unconditionally and never emit warnings.
* lib/Automake/VarDef.pm (VAR_COMPUTED): New.
(dump): Print it.
-working you patch accordingly?
I prefer to wait for 1/2 to be sorted out.
On 08/22/2012 12:44 PM, Paolo Bonzini wrote:
The old API for dist formats can be supported easily, by parsing the
AUTOMAKE_OPTIONS and generating AM_DIST_FORMATS from it, if not defined
otherwise.
* NG-NEWS: Document
On Wed, Aug 22, 2012 at 5:12 PM, Stefano Lattarini
stefano.lattar...@gmail.com wrote:
On 08/21/2012 06:03 PM, Paolo Bonzini wrote:
Looking at GNU Smalltalk, I see:
* warn for INCLUDES (vs. AM_CPPFLAGS)
Turns out this has already been done for ages (at least since 2003).
I'll just remove
Il 22/08/2012 23:52, Stefano Lattarini ha scritto:
I'd much rather a mandatory noisy warning period before a feature is
completely removed.
This would require a new category of warnings that are are unconditionally
show, regardless of strictness or any -Wnone option. As usual, patches
Il 23/08/2012 10:36, Stefano Lattarini ha scritto:
On 08/22/2012 12:32 PM, Paolo Bonzini wrote:
How would you diagnose a typo in here at Automake runtime?
bin_PROGRAMS = $(call user-func,args)
bin_PROGRAMS += $(if $(ON-CYGWIN),baz)
ifdef ON-CYGWIN
# Oops, this was meant
On Mon, Sep 19, 2011 at 18:39, Stefano Lattarini
stefano.lattar...@gmail.com wrote:
Just to be sure, you are not including
http://lists.gnu.org/archive/html/automake-patches/2010-11/msg00091.html
are you?
No, not yet at least.
Because, if I'm not reading it wrong (which I might be doing in
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
Il 03/01/2013 21:53, Stefano Lattarini ha scritto:
Severity: wishlist
[This is posted also to the automake and texinfo lists to ensure
a wider audience. Discussion should continue exclusively on the
bug-automake list, to avoid a cross-posting flood]
Automake-generated have for a long
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
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
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 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
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
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
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
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 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
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
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
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
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
65 matches
Mail list logo
