bug#23768: [PATCH] tests: adjust to ignore gzip 1.8+ warnings

This fixes a test failure when testing with gzip 1.8. * t/distcheck-no-prefix-or-srcdir-override.sh: Instead of testing for an empty 'stderr' file, check for a zero-line file once gzip warnings have been removed. --- t/distcheck-no-prefix-or-srcdir-override.sh | 6 +- 1 file changed, 5 insert

bug#22372: [PATCH] automake.in: fix deprecated regex syntax

Enrico Jorns skribis: > Running automake with perl >= 5.22.0 produces the warning > > Unescaped left brace in regex is deprecated, passed through in regex; > marked by <-- HERE in m/\${ <-- HERE ([^ \t=:+{}]+)}/ at > > /ptx/work/dude/ejo/temptest/nodistro.0/sysroots/x86_64-oesdk-linux/usr/

bug#16291: Use of /bin/rm

Stefano Lattarini skribis: > On 12/30/2013 09:55 PM, Ludovic Courtès wrote: >> >> [MEGA-SNIP] >> >> No; I’m asking because the tests specifically refer to /bin/rm. >> What’s the reason? >> > Copying from my first reply: > > Ludovic Courtès wro

bug#16291: Use of /bin/rm

Stefano Lattarini skribis: > On 12/30/2013 04:44 PM, Ludovic Courtès wrote: >> Stefano Lattarini skribis: >> >>> On 12/29/2013 10:49 PM, Ludovic Courtès wrote: >> >> [...] >> >>>> However, in general, I think packages should not rely on h

bug#16291: Use of /bin/rm

Stefano Lattarini skribis: > On 12/29/2013 10:49 PM, Ludovic Courtès wrote: [...] >> However, in general, I think packages should not rely on hardcoded file >> names, and instead use AC_PATH_PROG or similar mechanisms to get the >> right file name. >> > Not in

bug#16291: Use of /bin/rm

Hello! While upgrading the GNU system to Automake 1.14.1, I noticed that a few tests emit warnings like this: --8<---cut here---start->8--- SKIP: t/spy-rm.tap 1 # SKIP /bin/rm not found PASS: t/spy-rm.tap 2 - rm -f SKIP: t/spy-rm.tap 3 # SKIP /bin/rm not found

bug#10447: ‘parallel-test3.test’ doesn’t terminate on x86_64-unknown-freebsd8.2

Hi Stefano, Stefano Lattarini skribis: > On 01/07/2012 10:52 PM, Ludovic Courtès wrote: >> Hi, >> > Hi Ludo, thanks for the report. > >> ‘parallel-test3.test’ doesn’t terminate on x86_64-unknown-freebsd8.2. >> For some reason, the ‘make -j1 check’ stopped after

bug#10448: dist-xz and dist-gzip cannot be combined?

Hi, The ‘master’ branch of Automake fails to produce both a tar.gz and tar.xz tarball. The former is empty, apparently because the source tree gets removed after the tar.xz is created: --8<---cut here---start->8--- tardir=automake-1.11a && ${TAR-tar} chof - "$

bug#10447: ‘parallel-test3.test’ doesn’t terminate on x86_64-unknown-freebsd8.2

Hi, ‘parallel-test3.test’ doesn’t terminate on x86_64-unknown-freebsd8.2. For some reason, the ‘make -j1 check’ stopped after ‘foo4.test’, and thus the test sits forever waiting for ‘serial/test-suite.log’ to appear. Sorry I can’t provide more details. Does it ring a bell? Thanks, Ludo’.

bug#9026: Supporting $ACLOCAL_PATH?

Hello, On an FHS-style system, all macros are picked up from /usr/share/aclocal. Conversely, on a Stow/Nix-style installation, macros are to be found in /foo/automake/share/aclocal, /bar/guile/share/aclocal, /baz/pkg-config/share/aclocal, etc. It seems to me that the latter calls for user enviro

bug#7995: [PATCH 1/4] Documentation for Guile support.

Hi Ralf, Ralf Wildenhues writes: > +@example > +guile_GUILE = compiled-and-installed.scm > +nodist_guile_GUILE = not-distributed.scm > +guile_DATA = not-compiled.scm > +noinst_GUILE = compiled-but-not-installed.scm > +dist_noinst_DATA = just-distributed-blob.scm > + > +# object files will be ins

bug#7995: Guile support in Automake

Hi Ralf, Andy already answered most of your questions, I think. Ralf Wildenhues writes: > - The current tests assume _GUILE sources are distributed by default; > OTOH, _LISP are not. Rationale for this semantic difference? In a typical project, 90% of the .scm files are hand-written, and 10

Re: Intermittent test failures

Hello Ralf, Ralf Wildenhues writes: > In addition to the previously posted patch, I'm thus applyin the one > below, and merging both into master. master should be regression-free > now, the testsuite should hopefully pass consistently. I'm interested > in any remaining failures, spurious or no

Re: Intermittent test failures

Hi Ralf! Ralf Wildenhues writes: > * Ralf Wildenhues wrote on Sat, Jul 31, 2010 at 02:11:59PM CEST: >> * Ludovic Courtès wrote on Tue, Jul 27, 2010 at 11:08:39AM CEST: >> > FYI the Automake test suite currently fails on Hydra. The build at >> > http://hydra.n

Intermittent test failures

Hi, FYI the Automake test suite currently fails on Hydra. The build at http://hydra.nixos.org/build/502179 has 5 failures; the one at http://hydra.nixos.org/build/502171 has 2 failures, etc. Thanks, Ludo’.

Re: mtime of installed files

Hello! Ralf Wildenhues writes: > Now I need to ask in more detail: do you actually need "newer" or just > "not older"? Because if the latter, then you could just let the rule to > install $(nodist_foobar_DATA) depend on the rule to install > $(dist_foobar_SOURCES), the latter of which I assume

Re: mtime of installed files

Hi Ralf, Ralf Wildenhues writes: > * Ludovic Courtès wrote on Tue, Jul 20, 2010 at 06:28:46PM CEST: >> Background: Guile 1.9/2.0 has an auto-compilation feature whereby if a >> source file has no corresponding object file in the search path, or if >> the object file is

mtime of installed files

Hello, Background: Guile 1.9/2.0 has an auto-compilation feature whereby if a source file has no corresponding object file in the search path, or if the object file is older than the source file, then the source file is automatically recompiled and stored in ~/.cache/guile/ccache. Packages that u

Re: [PATCH] Fix sloppy tests for silent rules

Hi, Stefano Lattarini writes: > At Monday 05 July 2010, Ludovic Courtès wrote: > >> I noticed on NixOS GNU/Linux that silent*.test would randomly fail (see >> <http://hydra.nixos.org/build/477516>.) The reason is that these tests >> would fail if “mv” is found i

Re: [PATCH] Fix sloppy tests for silent rules

Oops, here’s the right patch: Make these tests more robust. Previously, they would fail if the name of the build directory contains `mv', which can very well happen with Nix. --- automake-1.11.1/tests/silent.test 2009-12-08 19:02:32.0 +0100 +++ automake-1.11.1/tests/silent.test 2010-07-0

[PATCH] Fix sloppy tests for silent rules

Hello, I noticed on NixOS GNU/Linux that silent*.test would randomly fail (see .) The reason is that these tests would fail if “mv” is found in the standard output of ‘make’, but the random build directory names used by Nix could very well contain this string.

Re: Directory names should use $(PACKAGE_TARNAME), not $(PACKAGE)

Hi, Peter Johansson writes: > This doesn't help you much, but if I set > AC_INIT([GNU Guile], [1.0], [em...@example.org]) > > I get (using autoconf 2.64 and automake 1.11): > PACKAGE = guile > PACKAGE_NAME = GNU Guile > PACKAGE_TARNAME = guile > > IIRC, the first one is set by automake and the t

Re: Directory names should use $(PACKAGE_TARNAME), not $(PACKAGE)

Hi Peter, Peter Johansson writes: > Ludovic Courtès wrote: >> Hello, >> >> I recently changed Guile so that PACKAGE is “GNU Guile” (instead of >> “guile”), while PACKAGE_TARNAME remains “guile”. >> >> > I wonder how you did that. Coul

Re: Directory names should use $(PACKAGE_TARNAME), not $(PACKAGE)

Hello, l...@gnu.org (Ludovic Courtès) writes: > 2. $(pkglibdir), $(pkgdatadir), etc., all use .../$(PACKAGE), but I > think it should really be .../$(PACKAGE_TARNAME). This is actually documented in Automake (info "(automake) Uniform"), but this choice conflicts with wh

Directory names should use $(PACKAGE_TARNAME), not $(PACKAGE)

Hello, I recently changed Guile so that PACKAGE is “GNU Guile” (instead of “guile”), while PACKAGE_TARNAME remains “guile”. In doing so, I noticed that: 1. $(distdir) is $(PACKAGE)-$(VERSION), but it should really be $(PACKAGE_TARNAME)-$(VERSION). 2. $(pkglibdir), $(pkgdatadir), etc.,

Re: preserving timestamps on installation

Hi Andy, Andy Wingo writes: > Where automake comes in is that installing a file touches its mtime, > always, not preserving the mtime of the file being installed. Could it be solved with an `install-hook' target that would touch all the installed `.go' files? Thanks, Ludo'.

Re: Cross-directory support

Hi, Roumen Petrov writes: > Ludovic Courtès wrote: >> Questions: >> >> 1. Is it possible to avoid repeating `src/' in the second case? >> >> 2. Can we somehow arrange the second case so that `libfoo' is built in >> `$top

Cross-directory support

Hello, A couple of questions about "cross-directory support" (info "(automake) Alternative"). Suppose the following layout: Makefile.am-> SUBDIRS = src src/ Makefile.am -> libfoo_SOURCES = a.c b.c c.c a.c b.c c.c Switching to a non-recursive `make' model goes like this:

Re: Failure of `make.test'

Hi, Stepan Kasal <[EMAIL PROTECTED]> writes: > In short, I'd recommend that NixOS reconsider the patch. I actually reached the same conclusion and posted that suggestion to the Nix mailing list: http://thread.gmane.org/gmane.linux.distributions.nixos/662 We'll see what happens... Thanks, Lu

Re: Failure of `make.test'

Hi, Ralf Wildenhues <[EMAIL PROTECTED]> writes: > You could also write a patch letting automake/m4/make.m4 drop that extra > output. Or at least show us what it is. The extra output [*] is (1) one line per goal sent to stderr, and (2) an additional "\e[p" sequence to stdout when `-w' is used:

Re: Failure of `make.test'

Hi, Stepan Kasal <[EMAIL PROTECTED]> writes: > It means that "make -w" behaves strange on your platform. (Try > replacing "make -w" with "make" at the top of the script; then the > answer will be "GNU", right?) > > You should report it to the vendor of your platform (NixOS). Yes, actually I had

Re: Failure of `make.test'

Hi, Stepan Kasal <[EMAIL PROTECTED]> writes: > to reproduce what the test does, try the following: Unfortunately, I can't run it with the in-tree Automake, because `autoreconf' won't find $prefix/share/aclocal-1.10, for instance. How can I make it use the in-tree files? > Attached below plea

Failure of `make.test'

Hi, This is with Automake 1.10.1 on GNU/Linux (NixOS), with Autoconf 2.62: /tmp/nix-build-asfyknxas01zm7gr00sw7z2h9jqszv8b-automake-1.10.1.drv-0/automake-1.10.1/tests:/nix/store/4p6cj78b188n649fjf1fz1gi3hl2dw40-perl-5.10.0/bin:/nix/store/cxc8hfhxayw773csnrsidsdr1dq9h55p-autoconf-2.62/bin:/nix/sto