m4-patches
[Top][All Lists]
Advanced

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

Re: parallel build bug in git M4


From: Eric Blake
Subject: Re: parallel build bug in git M4
Date: Wed, 18 Mar 2009 19:31:26 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.19) Gecko/20081209 Thunderbird/2.0.0.19 Mnenhy/0.7.6.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Ralf Wildenhues on 3/14/2009 6:36 AM:
> Hi Eric, all,
> 
> if my second patch for parallel build in GNUmakefile from this mail
> <http://thread.gmane.org/gmane.comp.sysutils.automake.bugs/4476>
> gets accepted into gnulib, then git master M4 will have a build bug, in
> that an update of a build tree may fail due to the rule for the manpage.
> More precisely, there are two issues:
> 
> The rule to update m4$(EXEEXT) is not atomic (which is ok for the rule
> itself, but not for the m4.1 rule).  The first thing it does is remove
> an old executable; so even when the re-creation of it happens to be
> atomic (it may not be; but testing for executability may be sufficient
> for the second part of the rule), the whole rule won't be.  This is
> relevant, because the rule for m4.1 tests for existence of the
> m4$(EXEEXT).
> 
> Also, testing for existence of m4$(EXEEXT) is not sufficient.  A
> parallel build may be in the process of updating one of the libraries
> that the program depends upon, while the m4.1 rule is run.  This can
> cause an error from help2man.
> 
> I have been thinking about this a bit, and the only real solution that
> I've found that doesn't involve other races or adding .NOTPARALLEL was
> to reintroduce a subdir makefile.  But then we can put all doc/ rules
> there again; see the patch below.  Do you see any other possibilities?

I'm still thinking about it.  Gary originally introduced the non-recursive
make; and for the source files and incremental builds, it makes a big
difference.  But the documentation doesn't have much that runs in
parallel, and making the man page occur in a recursive make doesn't seem
like too big a penalty from my point of view if it avoids the race.  I'd
really like to hear from Gary on this issue, though, before pushing anything.

>     Fix m4.1 build race, exposed by parallelism through GNUmakefile.
>     
>     * Makefile.am (SUBDIRS): Add doc.
>     (Documentation rules): Move ...
>     * doc/Makefile.am: ... to this new file.
>     * configure.ac (AC_CONFIG_FILES): Generate doc/Makefile.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknBoG4ACgkQ84KuGfSFAYCVyQCdEiDECN2IfckKeFzM2wdQCEIy
IbwAn1pW5DjvuylTqkBhz1vO+s6RwM9d
=53Z7
-----END PGP SIGNATURE-----




reply via email to

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