automake-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] avoid parallel build failures


From: Jim Meyering
Subject: Re: [PATCH] avoid parallel build failures
Date: Thu, 12 Apr 2012 10:24:07 +0200

Stefano Lattarini wrote:

> On 04/11/2012 09:27 PM, Jim Meyering wrote:
>> Surprised by parallel build failures,
>>
> Oops *blush* I must admit that, while I usually run the testsuite with
> a high degree of parallelism, I also usually run the build proper with
> a simple "make all", because that is so fast anyway.  So I ended up
> releasing the beta tarball without having truly tried a fully parallel
> build -- how foolish.  Do you think this issue warrants another beta
> release?
>
>> I tracked them down:
>>
>> From 3fcf1fe611140eb6677d5893719bec1d96f106db Mon Sep 17 00:00:00 2001
>> From: Jim Meyering <address@hidden>
>> Date: Wed, 11 Apr 2012 21:25:48 +0200
>> Subject: [PATCH] avoid parallel build failures
>>
> Minor tiny nit (feel free to ignore it): could you prepend the summary
> line with either "build:" or "fixup:", so that the guidelines in HACKING
> are followed?
>
>> A parallel build would fail when two concurrent sub-make processes
>> tried to build lib/Automake/Config.pm.  The loser would complain that
>>   grep: lib/Automake/Config.pm-t: No such file or directory
>>   chmod: cannot access `lib/Automake/Config.pm-t': No such file or\
>>     directory
>>   make[1]: *** [lib/Automake/Config.pm] Error 1
>> * Makefile.am (update_mans): Don't build lib/Automake/Config.pm here.
>> Instead, depend on it from the two rules that use it:
>> ($(srcdir)/doc/aclocal-$(APIVERSION).1): Depend on it.
>> ($(srcdir)/doc/automake-$(APIVERSION).1): Likewise.
>>
> Oops, a distributed file cannot depend on a non-distributed one :-(
> This makes the patch unusable unfortunately.

IMHO, there is only one way to work around this: don't distribute
those two files, i.e., generate them at build time.
That means either automake distributes the help2man script
(as coreutils does) or it adds help2man to its list of build-time
dependencies, as diffutils, cppi, libtool and others do.
Given automake's position in the system build-dependency graph
I have a slight preference to include help2man in the tarball.

The alternative is to try to guess at configure time whether
the "extra" dependencies are required[*].  If not, elide the
dependency and hope that the user does not run e.g.,
"make maintainer-clean", which would leave them with no doc/*.1
files and no reliable rules to rebuild them.

[*] the dependencies would be required when not building from a
tarball or when doc/*.1 do not exist.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]