automake-1.17 released [stable]

(2) Jim Meyering (10) Karl Berry (99) Kelvin M. Klann (1) Mark Wooding (1) Mathieu Lirzin (1) Matthew Leeds (1) Mike Frysinger (62) Olly Betts (1) Paul Eggert (13) Pavel Raiskup (2) Reuben Thomas (4) Richard Hopkins (3) Vincent Lefevre (1) Yves Orton (1) Zack Weinberg (5

Re: [platform-testers] automake-1.16.92 released

On Fri, Jun 21, 2024, 16:46 Bruno Haible wrote: > Jim Meyering wrote: > > We're particularly interested in bugs or regressions in the actual > > Automake functionality. > > I created a Gnulib testdir (of all of Gnulib) with automake-1.16.92, > and built that on v

automake-1.16.92 released

there now. ~~~ There have been 25 commits by 7 people in the 18 days since 1.16.90. Thanks to everyone who has contributed! The following people contributed changes to this release: Bruno Haible (2) Collin Funk (2) Jim Meyering (1) Karl

automake-1.16.90 released

3448 6D1E EA67 7FD9 FCCB 000B uid [ unknown] Jim Meyering uid [ unknown] Jim Meyering uid [ unknown] Jim Meyering If that command fails because you don't have the required public key, or that public key has expired, try the f

Re: small patch to make a test work with upcoming autoconf

I wrote: > One of autoconf's diagnostics changed a couple of months ago, > and an automake test depended on the precise wording of the > now-changed diagnostic. This change (will push shortly) > makes the automake test work with both the old and the new wording: ... > - grep 'possibly undefined .*

small patch to make a test work with upcoming autoconf

One of autoconf's diagnostics changed a couple of months ago, and an automake test depended on the precise wording of the now-changed diagnostic. This change (will push shortly) makes the automake test work with both the old and the new wording: tests: work also with v2.72-9-g7a6347d1 and newer *

1.16j: test release incoming

sc_sanity_gnu_grep GEN sc_perl_protos ./t/ax/test-defs.sh:# for this whole subsecond-mtime problem. With this set to "sleep 1", Do not use "sleep x" in the above tests. Use "$sleep" instead. make: *** [maintainer/syntax-checks.mk:443: sc_tests_plain_sleep] Error 1 So

Re: make check(s) pre-release problems

On Thu, Oct 6, 2022 at 1:28 PM Karl Berry wrote: > > No errors on RHEL7+autoconf2.71 > > Puzzling. Can you easily try RHEL8 or one of its derivatives? > It surprises me that that is the culprit, but it seems possible. > > I'm using autoconf-2.71, make-4.3, etc., compiled from source, but am >

fix: autoreconf fails due to .m4 files added but not installed

undefined macro: _AM_PROG_XARGS_N I've just pushed the attached fix. Introduced in v1.16.5-46-g38da1d906 and v1.16.5-45-g3099097d7 so this doesn't need a NEWS update. Mike, can you add an automake test that would have caught this? >From 208f103f2607eaed95aa0d227c5627b4363ffb7b Mon Sep 1

Re: How to speed up 'automake'

On Mon, May 23, 2022 at 1:48 PM Karl Berry wrote: > > I was going to bisect but if it doesn't fail for me in the first place... > :( > > Thanks. Indeed, reconfiguring etc. got rid of those errors. > > Now a bunch (12) of the Python tests are failing for me, presumably > because of previous Py

Re: How to speed up 'automake'

On Tue, May 3, 2022 at 2:57 PM Karl Berry wrote: > > I see no reason why mv would be so crucial. > > Hmm, I guess you're right. Thanks for the analysis. > > The purpose of the stamp files is to avoid partial files being written > (and screwing up future makes), but if the file is zero bytes, i

Re: How to speed up 'automake'

On Tue, May 3, 2022 at 3:55 PM Nick Bowler wrote: > > On 2022-05-02, Karl Berry wrote: > > - @echo '# dummy' >$@-t && $(am__mv) $@-t $@ > > + @: >>$@ > > > > 1) does it actually speed anything up? > > The answer seems to be a resounding "yes". I tried one of my packages > on an old slow

Re: Need better release validation documentation/strategy.

On Fri, Apr 8, 2022 at 6:30 AM Bob Friesenhahn wrote: > Today I saw an announcement for a new version of gzip. It provided > lots of data for how to verify the downloaded tarballs. I recently > saw a very similar announcement for a new version of libtool. I am not > sure where the template of th

Re: multiple online manual versions

On Tue, Jan 18, 2022 at 8:14 AM Mike Frysinger wrote: > currently the automake website only hosts one manual version -- the latest. > when working with older code bases, especially when trying to update them > to newer versions, it can be helpful to have the older manual available to > quickly ref

FYI, updated copyrights

FYI, I've just updated copyright messages for the new year: https://git.savannah.gnu.org/cgit/automake.git/commit/?id=6c8ff6a8f3c80f86e703a3fc2a0ffb81e87f0957

Re: [platform-testers] automake-1.16g snapshot

On Mon, Sep 20, 2021 at 12:03 AM Dagobert Michelsen wrote: > Hi Jim, > > Am 20.09.2021 um 04:37 schrieb Jim Meyering : > > We're preparing for a new release. > > See NEWS below. Please give it a spin and report any success or failure. > > > > Thanks

automake-1.16g snapshot

o has contributed! The following people contributed changes to this release: Akim Demaille (1) Dimitri Papadopoulos (1) Jan Engelhardt (1) Jim Meyering (2) Karl Berry (5) Nick Bowler (1) Jim [on behalf of the automake mainta

Re: automake-1.16d snapshot

On Sun, Jul 18, 2021 at 8:06 PM Jim Meyering wrote: > We're preparing for a new release, so here's the latest. > Please give it a spin and report any success or failure. > I'd like to release 1.16.4 within a week or so. > > Thanks to Karl yet again for doing so mu

automake-1.16d snapshot

1.16.3. See the NEWS below for a brief summary. Thanks to everyone who has contributed! The following people contributed changes to this release: Allison Karlitskaya (2) Dirk Mueller (1) Jacob Bachmeyer (1) Jim Meyering (7) Joshua Root (1) Karl Berry (25) Mike Frysinger (1)

Re: Automake testsuite misuses DejaGnu

On Sun, Jul 11, 2021 at 9:03 PM Jacob Bachmeyer wrote: > I was planning to find a solution with a complete patch before > mentioning this, but since a release is imminent I will just state the > problem: several tests in the Automake testsuite misuse DejaGnu and > fail with the 1.6.3 DejaGnu rele

snapshot imminent

Karl and I have just pushed a few changes (thanks, Karl and Allison!). With those, I think we're ready for a release. I will make the usual pre-release snapshot, probably tomorrow.

automake-1.16.3 released [stable]

. Thanks to everyone who has contributed! The following people contributed changes to this release: Akim Demaille (1) Colomban Wendling (1) Felix Yan (1) Issam E. Maghni (1) Jim Meyering (12) Karl Berry (23) Miro Hron\v{c}ok (1) Paul Eggert (4) Reuben Thomas (3) Robert Menteer (1

Re: problems with "make install" directory permissions

On Mon, Jul 27, 2020 at 3:03 PM Paul Eggert wrote: > > On 7/27/20 2:24 PM, Karl Berry wrote: > > https://lists.gnu.org/r/bug-bison/2020-07/msg00042.html > > > > I can understand increasing permissions to allow +rx on installation > > directories, but why force 755, thus disallowing group writ

automake-1.16.2 released [stable]

NEWS below for a brief summary. Thanks to everyone who has contributed! The following people contributed changes to this release: Bruno Haible (1) Gavin Smith (1) Giuseppe Scrivano (1) Jim Meyering (5) Karl Berry (12) Libor Bukata (1) Lukas Fleischer (2) Mathieu Lirzin (8) Paul

Re: dependency tracking error message

On Thu, Feb 13, 2020 at 6:40 PM Karl Berry wrote: > Looking at the automake-patches that have accumulated, I saw one to > improve the error message if dependency tracking fails. Copied below. > > It seems generally sensible to me, though I would change the wording a > little, and there is a spurio

Re: t/aclocal-print-acdir.sh at installcheck and AUTOMAKE_UNINSTALLED

On Mon, Feb 3, 2020 at 6:23 PM Karl Berry wrote: > The aclocal-print-acdir.sh test fails at the make installcheck step of > make distcheck (it succeeds in the normal make check, and it succeeds at > the make check of make distcheck; only fails in the make installcheck). > > This is because AUTOMAK

FYI: fixing "maintainer-check" tests

I've just fixed some FP nits: [PATCH] maint: make maintainer-check tests pass * maintainer/syntax-checks.mk (sc_sanity_gnu_grep): Remove NUL byte from grep output, to avoid shell diagnostic about "NUL byte suppressed from expansion." (automake_diff_no, aclocal_diff_no): Adjust number of expected

Re: t/txinfo-vtexi4.sh and timezone failure

On Fri, Dec 20, 2019 at 6:15 PM Karl Berry wrote: > > The automake test t/txinfo-vtexi4.sh failed when localtime and UTC were > on different days, resulting in the GREPDATE for the @UPDATED@ string > not matching (among possible others). > > mdate-sh always uses TZ=UTC0. This tiny change makes the

Re: __pycache__ directories and distcleancheck

Thanks for the report. Would you please create a minimal set-up to demonstrate the problem? That will probably expedite a proper fix. On Wed, Jun 13, 2018, 11:56 Adam Mercer wrote: > Hi > > We've recently updated our code to support Python3 and are running > into a problem with __pycache__ direc

Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer

On Mon, Dec 11, 2017 at 11:03 AM, Jim Meyering wrote: > On Mon, Dec 11, 2017 at 9:56 AM, Glenn Morris wrote: >> >> Jim Meyering wrote (on Sun, 10 Dec 2017 at 17:01 -0800): >> >>> However, I don't see how "-f batch-byte-compile" can be used when >

Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer

On Mon, Dec 11, 2017 at 9:56 AM, Glenn Morris wrote: > > Jim Meyering wrote (on Sun, 10 Dec 2017 at 17:01 -0800): > >> However, I don't see how "-f batch-byte-compile" can be used when >> the .elc file must be created in a directory separate from the one >

Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer

On Wed, Nov 29, 2017 at 12:17 PM, Glenn Morris wrote: > The obsolete bytecomp feature is back as of Emacs 9964db4. Thanks, I noticed when that was restored, but have been a way for a while. > BTW, why doesn't lisp.am use the standard "-f batch-byte-compile" > method of producing .elc files? > >

Re: [PATCH] "make dist" did not depend on $(BUILT_SOURCES)

On Tue, Nov 28, 2017 at 8:35 PM, Nick Bowler wrote: > On 2017-11-28 18:13 -0800, Jim Meyering wrote: >> On Tue, Nov 28, 2017 at 12:45 PM, Nick Bowler wrote: >> > The Automake manual unequivocally states that BUILT_SOURCES files are >> > generated only when running

Re: [PATCH] "make dist" did not depend on $(BUILT_SOURCES)

On Tue, Nov 28, 2017 at 12:01 PM, Mathieu Lirzin wrote: > Hello Jim, ... >> >> Here's the patch I expect to push to master: ... > > OK to push. Thanks. Pushed. I have also removed the micro branch.

Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer

On Tue, Nov 28, 2017 at 2:23 PM, Glenn Morris wrote: > Jim Meyering wrote: > >> Remember: this arises only in a non-srcdir build. That means build >> artifacts end up being written into the mostly-empty current directory >> hierarchy, which does not have copies of t

Re: [PATCH] "make dist" did not depend on $(BUILT_SOURCES)

On Tue, Nov 28, 2017 at 12:45 PM, Nick Bowler wrote: > Hi Jim, > > On 2017-11-28 11:21 -0800, Jim Meyering wrote: >> Date: Thu, 20 Mar 2014 12:31:32 -0700 >> Subject: [PATCH] "make dist" did not depend on $(BUILT_SOURCES) >> >> * lib/am/distd

[PATCH] "make dist" did not depend on $(BUILT_SOURCES)

is: src/hello.c:27:10: fatal error: configmake.h: No such file or directory #include "configmake.h" ^~ Here's the patch I expect to push to master: From: Jim Meyering Date: Thu, 20 Mar 2014 12:31:32 -0700 Subject: [PATCH] "make dist" did no

Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer

On Mon, Nov 27, 2017 at 8:12 PM, Jim Meyering wrote: > On Mon, Nov 27, 2017 at 12:52 PM, Jim Meyering wrote: >> On Mon, Nov 27, 2017 at 10:27 AM, Glenn Morris wrote: >>> Jim Meyering wrote: >>> >>>> In May of 2017, support for using the long-deprecated &

Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer

On Mon, Nov 27, 2017 at 12:52 PM, Jim Meyering wrote: > On Mon, Nov 27, 2017 at 10:27 AM, Glenn Morris wrote: >> Jim Meyering wrote: >> >>> In May of 2017, support for using the long-deprecated >>> byte-compile-dest-file function was removed, and that removal bro

Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer

On Mon, Nov 27, 2017 at 10:27 AM, Glenn Morris wrote: > Jim Meyering wrote: > >> In May of 2017, support for using the long-deprecated >> byte-compile-dest-file function was removed, and that removal broke >> automake's elisp-compiling rule for any .el file not in the

Re: Update HACKING (was: [PATCH] port elisp-compilation support to emacs-23.1 and newer)

On Fri, Nov 24, 2017 at 4:42 AM, Mathieu Lirzin wrote: > Mathieu Lirzin writes: > >> Indeed HACKING is not up-to-date, I will fix that. > > Here is a patch that should help describing the new branching model more > accurately. If you see further improvements or would prefer different > wording,

Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer

On Thu, Nov 23, 2017 at 3:57 PM, Mathieu Lirzin wrote: > Hello Jim, > > Jim Meyering writes: > >> On Thu, Nov 23, 2017 at 7:38 AM, Jim Meyering wrote: >>> I wanted to make a new idutils release, but was blocked because >>> its "make distcheck" would

Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer

On Thu, Nov 23, 2017 at 7:38 AM, Jim Meyering wrote: > I wanted to make a new idutils release, but was blocked because > its "make distcheck" would fail. That was because it distributes > and builds from an elisp file, and automake's elisp-compilation > rule uses

[PATCH] port elisp-compilation support to emacs-23.1 and newer

ht: https://lists.gnu.org/archive/html/emacs-devel/2017-11/msg00551.html >From ecad5844100d5193ecd58f66f31f6bbf0ef04e23 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Wed, 22 Nov 2017 21:07:29 -0800 Subject: [PATCH] port elisp-compilation support to emacs-23.1 and newer In May of 2017, support f

FYI: update copyright dates for 2017

FYI, I've just pushed a commit to update copyright dates: maint: update copyright dates for 2017 * all files: Run this command, using update-copyright from gnulib: UPDATE_COPYRIGHT_FORCE=1 \ UPDATE_COPYRIGHT_USE_INTERVALS=2 \ UPDATE_COPYRIGHT_MAX_LINE_LENGTH=79 \ update-copyr

Re: AM_PROG_MKDIR_P: too soon to obsolete this macro?

Stefano Lattarini wrote: > On 09/12/2012 09:20 PM, Jim Meyering wrote: >> Stefano Lattarini wrote: >>> On 09/12/2012 06:04 PM, Jim Meyering wrote: >>>> I see that gettext (latest from git) still AC_REQUIRE's >>>> AM_PROG_MKDIR_P from its intl.m4 an

Re: AM_PROG_MKDIR_P: too soon to obsolete this macro?

Stefano Lattarini wrote: > On 09/12/2012 06:04 PM, Jim Meyering wrote: >> I see that gettext (latest from git) still AC_REQUIRE's >> AM_PROG_MKDIR_P from its intl.m4 and po.m4 files, which >> are pulled into *many* projects. >> > I know. I sent a patch severa

AM_PROG_MKDIR_P: too soon to obsolete this macro?

I see that gettext (latest from git) still AC_REQUIRE's AM_PROG_MKDIR_P from its intl.m4 and po.m4 files, which are pulled into *many* projects. When I try to build one of those projects (coreutils) using the latest from automake.git/master, I see this failure: $ aclocal -I m4 configure.a

libvirt build failure w/GNU make and automake.git (automake regression?)

When I run ./autogen.sh && make, I see this: (this arose because I had the latest automake.git/master tools -- commit c1b83e1af60b866cf5cdeebf77d0275019bad8b2 from today -- early in my path) Generated 3 wrapper functions CC libvirtmod_la-libvirt-override.lo CC libvirt

latest automake makes emacs bootstrap fail

Just a heads up: In the very latest automake (from git), $MISSING is now invoked with the --is-lightweight option. That new usage causes emacs' bootstrap (also from git) to fail because its missing script does not yet know about the --is-lightweight option. In my case, I've simply copied automak

Re: parallel "make check" output lines are lost!?!

Stefano Lattarini wrote: > Hi Jim. > > On 08/01/2012 04:52 PM, Jim Meyering wrote: >> I ran coreutils "make check" tests 60 times (on Fedora 17, x86_64), >> recording the results of each run like this: >> >> for i in $(seq 100); do make -j25 che

parallel "make check" output lines are lost!?!

I ran coreutils "make check" tests 60 times (on Fedora 17, x86_64), recording the results of each run like this: for i in $(seq 100); do make -j25 check -C tests VERBOSE=yes \ RUN_EXPENSIVE_TESTS=no >& makerr-$i &&t=.||t=X; printf $t; done They all passed, but I decided to compare a few

Re: GNU Automake 1.12.1 released

Stefano Lattarini wrote: > On 07/09/2012 11:45 AM, Stefano Lattarini wrote: >> On 07/09/2012 11:17 AM, Jim Meyering wrote: >>>> >>>> - - The long-obsolete (since automake 1.10) @mkdir_p@ configure-time >>>> -substitution and AM_PROG_MKDIR m4 mac

Re: GNU Automake 1.12.1 released

Stefano Lattarini wrote: > On 07/09/2012 09:22 AM, Jim Meyering wrote: >> >> Hi Stefano, >> >> I see that @mkdir_p@ is used in gettext's Makefile.in.in template: >> >> # We use $(mkdir_p). >> # In automake <= 1.9.x, $(mkdir_p) is defined

Re: GNU Automake 1.12.1 released

Stefano Lattarini wrote: > On 07/06/2012 12:10 AM, Diego Elio Pettenò wrote: >> Il 05/07/2012 11:26, Stefano Lattarini ha scritto: >>> How so? Removal of $(mkdir_p) is only planned for Automake 1.13, that is >>> still unreleased. >> >> Ehm Stefano, that's definitely not the case, I've been hitting

Re: [RFC] Releasing automake 1.11.2

Stefano Lattarini wrote: > References: > > > > At this point I think we are ready to release a beta version of 1.11.2, > and then ask for help on platform-testers to smoke out

Re: [RFC] Releasing automake 1.11.2

Stefano Lattarini wrote: > Hello automakers. > > I think it's about time to release automake 1.11.2 -- the `maint' > branch contains various bug fixes w.r.t. the 1.11.1 release (some > of them quite important), and offers some new small features and > various warnings/deprecations that should prepa

Re: bug#8616: conflict between build-aux/compile script and coreutils Makefiles

Green, Paul wrote: > Gentle Coreutils Developers, > > I am writing to notify you of an issue that I stumbled across while > building coreutils-8.12 on the Stratus OpenVOS platform. Hi Paul, Thanks for the detailed report. I'm Cc'ing the automake list, since that's the source of the compile script

Re: bug#8616: conflict between build-aux/compile script and coreutils Makefiles

Stefano Lattarini wrote: > On Thursday 05 May 2011, Jim Meyering wrote: >> Green, Paul wrote: >> > Gentle Coreutils Developers, >> > > [HUGE CUT] >> >> To the automake folks, is there any reason not to do that? >> > > Hi Jim. I'm in

bug#8621: build-aux/compile: avoid race condition failure

Is there any reason not to make the compile script accommodate (in a race-free manner) situations like the one described in http://debbugs.gnu.org/8616 ?

Re: [coreutils] debbugs

Ralf Wildenhues wrote: > [ sorry for the xpost; please followup to the automake list, replyto set ] > > Hello coreutils developers, > > Gary was nice to point us at the debbugs you're using now for your bugs > list. How do you like it, how's it working for you, Hi Ralf, yes I'm happy with it. >

Re: absolute build directory with spaces

Stefano Lattarini wrote: > On Saturday 04 September 2010, Bruno Haible wrote: >> Hi, >> >> Jim Meyering wrote on bug-gnulib: >> > Coreutils tests with an absolute build directory name that >> > contains a space. Not quoting this directory name caused a &

Re: absolute build directory with spaces

Bruno Haible wrote: > Jim Meyering wrote on bug-gnulib: >> Coreutils tests with an absolute build directory name that contains >> a space. Not quoting this directory name caused a failure. >> * tests/test-vc-list-files-git.sh: Quote PATH dir name. >> ... >> ---

Re: dist-xz compression level

Pavel Sanda wrote: >> Pavel Sanda wrote: >> It was deliberate. >> For my use, xz -9 is far too slow for anything except the >> final "make dist" I run just prior to a release. >> >> For a release, I run this, via one of the >> alpha, beta or stable targets in gnulib's maint.mk: >> >> $(MAKE) dist

Re: dist-xz compression level

Pavel Sanda wrote: > the newly added dist-xz target produce worse compressed archives > than lzma-dist. The reason is that automake call lzma with > best compression while it won't use -9 level for xz. > Is this intention or bug? It was deliberate. For my use, xz -9 is far too slow for anything ex

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

Ralf Wildenhues wrote: > * Jim Meyering wrote on Sun, Dec 13, 2009 at 11:44:15AM CET: >> Paolo Bonzini wrote: >> > This rule could actually be moved to Automake's distcheck target. >> >> Good idea. >> FYI, here's the definition I have now: >> (a

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

Paolo Bonzini wrote: > 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 \ >>

Re: writability of directories in distributions

Bob Friesenhahn wrote: > On Sat, 28 Nov 2009, Harlan Stenn wrote: >> I just saw a patch go by about changing the perms on directories in >> distribution tarballs. >> >> I'm a fan of 775 myself (ok, I really prefer 2775). >> >> But I can see that some would prefer 777, and others would prefer 755. >

Re: writability of directories in distributions

Harlan Stenn wrote: > I just saw a patch go by about changing the perms on directories in > distribution tarballs. > > I'm a fan of 775 myself (ok, I really prefer 2775). > > But I can see that some would prefer 777, and others would prefer 755. > > The other issue, as I recall, has to do with whet

Re: permissions of files in dist tarball

Ralf Wildenhues wrote: > Hello Alan, Jim, > * Jim Meyering wrote on Sun, Nov 22, 2009 at 04:32:57PM CET: >> Alan Curry wrote: >> > So was the drwxrwxrwx in the tarball put there to teach a lesson to those >> > who trust a tarball to have sane permissions? Or is it a b

Re: stable coreutils-8.1 today, fingers crossed

Alan Curry wrote: > Jim Meyering writes: >> >> Gilles Espinasse wrote: >> ... >> >> [chroot-i486] root:/$ umask >> >> 0022 >> >> [chroot-i486] root:/$ rm -rf /usr/src/coreutils* >> >> [chroot-i486] root:/$ cd /usr/src

using color-tests backwards-portably

Hi Ralf, I'd like to use automake-1.11's color-tests option in libguestfs -- and more importantly, parallel-tests, but we may have a build-from-clone requirement on systems with automake older than 1.11. On those systems, it's fine to ignore or disable these two unsupported options. I proposed a

Re: choosing the default for silent-rules

Ralf Wildenhues wrote: > * Jim Meyering wrote on Sun, Apr 19, 2009 at 01:34:50PM CEST: >> Switching to silent-rules feels like progress, so I want it to be >> enabled by default, at least for packages I maintain. Of course, >> that's my judgment, and if enough p

Re: choosing the default for silent-rules

Ralf Wildenhues wrote: > * Jim Meyering wrote on Sun, Apr 19, 2009 at 10:53:40AM CEST: >> What if a package maintainer wants to enable >> automake's silent-rules option by default? > > Then you should argue for this; see the arguments against it here: ... Hi Ralf, I thi

choosing the default for silent-rules

What if a package maintainer wants to enable automake's silent-rules option by default? Currently, even when I use AM_INIT_AUTOMAKE([silent-rules]) it's disabled, and to get the behavior I want, I have to run ./configure --enable-silent-rules or "make V=0". Is there a recommended way to make the "

Re: [PATCH] build: use automake's --silent-rules option when possible

Thomas Dickey wrote: > On Sun, 29 Mar 2009, Jim Meyering wrote: >> Ralf Corsepius wrote: >>> Jim Meyering wrote: >>>> I like automake's upcoming --silent-rules option enough >>>> that I'm making it the default (when possible) for coreutils.

Re: [PATCH] build: use automake's --silent-rules option when possible

Ralf Corsepius wrote: > Jim Meyering wrote: >> I like automake's upcoming --silent-rules option enough >> that I'm making it the default (when possible) for coreutils. > Well, if you think such a step to be helpful, I disagree. Then you can build with "make

[PATCH] build: use automake's --silent-rules option when possible

con CCLD who CCLD chgrp CCLD chown CCLD chmod ... rather than less-readable lines full of gcc command-line options. >From 9f39fa8559a8f87e1199f11f6cee295ac8cf6781 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Sat, 28 Mar 2009 12:48:24 +0100 Subject: [PATCH] build: use automake's

Re: lzip support

Bob Friesenhahn <[EMAIL PROTECTED]> wrote: > On Sat, 29 Nov 2008, Jim Meyering wrote: >> I have been following lzma-utils development closely for some time, >> and my impression is that xz obviates lzip. I would not want to >> encourage use of lzip without a convinci

Re: lzip support

Jan Engelhardt <[EMAIL PROTECTED]> wrote: > On Saturday 2008-11-29 10:06, Jim Meyering wrote: >>Jan Engelhardt <[EMAIL PROTECTED]> wrote: >>> On Friday 2008-11-28 17:21, Bob Friesenhahn wrote: >>>> Since LZIP support has appeared apparently out of the b

Re: lzip support

Jan Engelhardt <[EMAIL PROTECTED]> wrote: > On Friday 2008-11-28 17:21, Bob Friesenhahn wrote: >> Since LZIP support has appeared apparently out of the blue (no >> prior discussion on this list), and Automake already had LZMA >> support, can someone please explain LZIP vs LZMA and why we now >> hav

Re: not hardwiring gpg

Ralf Wildenhues <[EMAIL PROTECTED]> wrote: ... > So, please commit, and e.g., put the first paragraph of your reply in > the log. Ah. That makes sense. Done.

NEWS: added support for lzma compression

FYI, I added support for LZMA[1] compression a few days ago: http://lists.gnu.org/archive/html/automake-patches/2007-10/msg3.html So now you can put this in your configure.ac file AM_INIT_AUTOMAKE([dist-lzma]) and "make dist" will generate both .gz and .lzma compressed tarballs. This sta

Re: read-only git mirror of automake cvs repository

Benoit SIGOURE <[EMAIL PROTECTED]> wrote: > On Oct 8, 2007, at 5:05 PM, Jim Meyering wrote: > >> I've set up a read-only git mirror of the automake cvs repository: > > Thank you! > >> >> http://sources.redhat.com/git/gitweb.cgi?p=automake.git >&g

read-only git mirror of automake cvs repository

I've set up a read-only git mirror of the automake cvs repository: http://sources.redhat.com/git/gitweb.cgi?p=automake.git It is updated from cvs every 15 minutes, but due to the way cvsps works, it may take two iterations for a change in cvs to propagate into the git tree.

Re: multiple cpu's

Benoit SIGOURE <[EMAIL PROTECTED]> wrote: > On Aug 12, 2007, at 11:09 PM, Ralf Wildenhues wrote: > >> Hello Jim, >> >> * Jim Meyering wrote on Sun, Aug 12, 2007 at 12:46:20PM CEST: >>> >>> On a related note, it'd sure be nice if &qu

Re: multiple cpu's

Ralf Wildenhues <[EMAIL PROTECTED]> wrote: ... >> OK, so it generates Makefile's that are fully capable of handling the -j >> switch to make? > > Mostly. Problems should be reported, please include a copy of the make > output of the failed build. Hi Ralf, On a related note, it'd sure be nice if

Re: race condition gnulib-tool's mostlyclean-local rule

Ralf Wildenhues <[EMAIL PROTECTED]> wrote: ... > IMVHO it's ugly (and resource-wasting) to have a $(MAKE) reinvocation > to paper over limitations in the extensibility of Automake-generated > Makefiles; the right fix would be to add dependency information > mostlyclean-local: mostlyclean-compile

race condition gnulib-tool's mostlyclean-local rule

For some modules (e.g., sys_stat), gnulib-tool generates a mostlyclean-local rule like this: mostlyclean-local: @test -z "$(MOSTLYCLEANDIRS)" ||\ for dir in $(MOSTLYCLEANDIRS); do \ if test -d $$dir; then \ echo "rmdir $$dir"; rm

Re: aclocal 1.8 no longer loads overridden macros

Alexandre Duret-Lutz <[EMAIL PROTECTED]> wrote: > Andreas> With aclocal 1.8 you no longer get overridden standard > Andreas> autoconf macros loaded from local *.m4 files. > >> > >> I could not reproduce this (tried to redefine AC_PROG_CC > >> successfully). Can you send detailed instructions?

Re: warning about _-variables

Alexandre Duret-Lutz <[EMAIL PROTECTED]> wrote: ... > Jim> What do you think about dropping that warning altogether, > Jim> or at least allowing packages like the coreutils to > Jim> disable that part of -Wall? ... > How can we do this? Shall we split -Wportability into two > options? How woul

multiple definition of e.g., bin_PROGRAMS

Hi Alexandre! I noticed recently that there are two definitions of bin_PROGRAMS in coreutils' src/Makefile.in. One that's identical to the original in src/Makefile.am, and another, better one, that follows most of the rules copied from Makefile.am. Is this intentional? That doesn't seem like a

FYI: install-sh: work with names containing spaces

\ y $ ls /tmp/x\ y a\ b* I've just checked in this change: 2002-11-09 Jim Meyering <[EMAIL PROTECTED]> Make install-sh work even when names contain spaces or certain (but not all) shell metachars. * lib/install-sh: Remove lots of unnecessary quoting.

suggestion for lib-link.m4: require config.rpath

result is that config.rpath is not in those tarballs. I only noticed it a few minutes ago when I actually watched the output of configure and noticed the error message about the missing file: config/config.rpath. Any objections? 2002-03-05 Jim Meyering <[EMAIL PROTECTED]> * automake.in

Re: proposed change for depout.m4

Alexandre Duret-Lutz <[EMAIL PROTECTED]> wrote: > On Sun, Feb 17, 2002 at 08:35:31PM +0100, Jim Meyering wrote: >> >> * m4/depout.m4: Don't use `head -1'; it's no longer portable. >> Use `sed 1q' instead. >> > > Hi Jim! C

Re: proposed change for depout.m4

1q $mf | fgrep 'generated by automake') > /dev/null 2>&1; then dirpart=`AS_DIRNAME("$mf")` else dirpart= Ralf Corsepius <[EMAIL PROTECTED]> wrote: > Am Son, 2002-02-17 um 18.19 schrieb Jim Meyering: >> Does anyone know of a system for which `head -n1' doesn't work >> the same as the traditional `head -1'? > >>From SunOS4's manpage (dated ~1990): ...

proposed change for depout.m4

Does anyone know of a system for which `head -n1' doesn't work the same as the traditional `head -1'? The latter doesn't conform to POSIX 1003.1-2001. Without this patch, dependencies don't work when using `head' from the next test release of the GNU textutils and with the `conform-to-latest-POS

AC_CONFIG_AUX_DIR now required when mdate-sh resides in subdir?

Hi Derek, Recently, automake changed so that I get the following in fileutils-4.1, even though I've put a copy of mdate-sh (though not in the official tarball) in doc/. $ automake --gnits --include-deps doc/Makefile.am:2: required file `./mdate-sh' not found I don't use AC_CONFIG_AUX_DIR.

m4/strip.m4 is still broken

Here's the patch you've seen at least twice before. Yeah, yeah, I know that there was some discussion about alternate (more invasive?) plans to fix the problem, but in the mean time, how about this one: Any objections? Index: m4/strip.m4 ==

typo? s/variable_dump/macro_dump/

I found it strange that this code (head of the module in cvs) seemed to work fine when I ran `make check' but failed right away after I'd installed it in a clean hierarchy and tried to use it. 2001-05-14 Jim Meyering <[EMAIL PROTECTED]> * automake.in (macro_def

  1   2   >