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: Stefano Lattarini
Subject: Re: [PATCH] avoid parallel build failures
Date: Thu, 12 Apr 2012 13:12:56 +0200

On 04/12/2012 10:24 AM, Jim Meyering wrote:
> 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.
>
That's seems the easiest and safest way out, especially considering
that Automake already requires per anyway.  Care to write a patch?
Otherwise I should be able to get to it by this evening or tomorrow
(as more serious issues with Vala support requires urgent attention
now).

> 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.
>
Sounds icky; I'd rather go with your other proposed solution.

Thanks for tacking this,
  Stefano



reply via email to

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