Re: Want "make check" to test shared, static lib

Il 20/11/2013 09:47, Torbjorn Granlund ha scritto: > Christian Rössel 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 are > looking for

Re: autotest, automake & non-recursive makes

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 ' [$

Re: [Help-smalltalk] [PATCH] build: drop useless AC_SUBST of 'INCLUDES'

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 wil

Re: [PATCH] build: use AC_CONFIG_HEADERS, not AM_CONFIG_HEADER

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, >&g

Re: [PATCH] build: use AC_CONFIG_HEADERS, not AM_CONFIG_HEADER

+ b/ChangeLog > @@ -1,3 +1,8 @@ > +2012-12-29 Stefano Lattarini(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 > > *

Re: [Automake-NG] typo whitelisting, and Automake-NG vs. GNU make runtime

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 &g

Re: [PATCH] {master} compile: remove support for $(INCLUDES)

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,

Re: [PATCH] {master} compile: remove support for $(INCLUDES) (was: Re: Automake vs. Automake-NG)

On Wed, Aug 22, 2012 at 5:12 PM, Stefano Lattarini 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 l

typo whitelisting, and Automake-NG vs. GNU make runtime

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 $va

Re: Automake vs. Automake-NG

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 >>

Re: Automake vs. Automake-NG

On Tue, Aug 21, 2012 at 9:10 PM, Stefano Lattarini 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

Re: Automake vs. Automake-NG

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 _SOUR

Re: Automake vs. Automake-NG

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 incompatiblitie

Re: Automake vs. Automake-NG

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?

Re: Automake vs. Automake-NG

>> 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 th

Re: Automake vs. Automake-NG

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: > >

Re: Automake vs. Automake-NG

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 usin

Re: Automake vs. Automake-NG

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 --

Re: Automake vs. Automake-NG

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 differen

Re: [PATCH] build: support and require Automake-NG

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_SOUR

Re: [gnu-prog-discuss] Could automake-generated Makefiles required GNU make?

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) has

Re: [gnu-prog-discuss] Could automake-generated Makefiles required GNU make?

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 suc

Re: [gnu-prog-discuss] Could automake-generated Makefiles required GNU make?

On 11/22/2011 01:13 PM, Stefano Lattarini wrote: > When we introduced shell functions into Autoconf, and in general updated > Autoconf/M4sh/libtool for relatively new shells (new = newer than > Ultrix), it was successful exactly because no one noticed! Maybe a first step would be to rewrite m

Re: [gnu-prog-discuss] Could automake-generated Makefiles required GNU make?

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

[RFC] AM_ARG_ENABLE

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 on

Re: [PATCH 0/2] Re: ifdef expessions in Makefile.am

On 12/22/2009 09:38 AM, Joakim Tjernlund wrote: bonz...@gnu.org wrote on 22/12/2009 09:16:59: From: Paolo Bonzini Here is where I was at. After that it was not immediate how to use a tag-dependent cache variable. Strictly speaking however using a cache variable is not needed to make the PIC

Re: [PATCH] maint.mk (null_AM_MAKEFLAGS, built_programs): remove unused definitions

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

Re: Define a complete rule via autoconf (quoting issue, AC_SUBST)

> 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

Re: profile-directed optimization

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 k

Re: Workarounds for "automake does not support info_TEXINFOS being defined conditionally"

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:

[Fwd: gnuplot sed error]

Here's it for you, a bug in the "missing" script. Paolo --- Begin Message --- 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 /home/dholt/g

Re: New snprintfv on CVS

I understood the problem was with snprintfv, not with autogen. What are you using INFO_DEPS for? I think it is undocumented and internal to automake, maybe autogen_texi_DEPENDENCIES or something like that works (but I do not know if it actually exists...). Paolo

Last patch I'd like to go in 2.60

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 toget

Has automake been adapted to autoconf 2.50?

If not, I have done the necessary work and can prepare a patch (I'm not including it because I had the great idea of working directly on the installed scripts and data files, so preparing the patch might involve some work...) -- |_ _ _ __ |_)(_)| ) ,' '-._