From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?Fran=C3=A7ois_Pinard?= Subject: Re: Reloading uncompiled and testing from several git branches Date: Mon, 18 Feb 2013 20:17:49 -0500 Message-ID: <86wqu55cg2.fsf@iro.umontreal.ca> References: <877gmvalzn.fsf@gmail.com> <87vcae53fi.fsf@bzg.ath.cx> <87haly96xi.fsf@gmail.com> <87zjzqejhz.fsf@bzg.ath.cx> <87wquumhqk.fsf@gmail.com> <87wquth35i.fsf@bzg.ath.cx> <87ehh12gjp.fsf@gmail.com> <87halsat2l.fsf@bzg.ath.cx> <87lib33o0u.fsf@Rainer.invalid> <87wqu81una.fsf@bzg.ath.cx> <874nhc36j4.fsf@Rainer.invalid> <87ehggo8db.fsf@bzg.ath.cx> <87zjz41r1h.fsf@Rainer.invalid> <87621s1jnr.fsf@ericabrahamsen.net> <87r4kgmlym.fsf_-_@bzg.ath.cx> <87vc9s1h9t.fsf@Rainer.invalid> <86wqu7ajjw.fsf@iro.umontreal.ca> <87lial5t4r.fsf@Rainer.invalid> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([208.118.235.92]:59436) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7bqE-0003Kl-1N for emacs-orgmode@gnu.org; Mon, 18 Feb 2013 20:17:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U7bqB-0004zr-Sr for emacs-orgmode@gnu.org; Mon, 18 Feb 2013 20:17:53 -0500 Received: from 206-248-137-202.dsl.teksavvy.com ([206.248.137.202]:53231 helo=mercure.bureau.ubity.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7bqB-0004ye-Lk for emacs-orgmode@gnu.org; Mon, 18 Feb 2013 20:17:51 -0500 In-Reply-To: <87lial5t4r.fsf@Rainer.invalid> (Achim Gratz's message of "Mon, 18 Feb 2013 20:17:24 +0100") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Achim Gratz writes: > Fran=C3=A7ois Pinard writes: >> Any Makefile which lists dependencies while expecting them to be >> satisfied sequentially, one after another, is broken. Make does not >> (theoretically) guarantee the order, while in practice, all "make" >> programs I know satisfy dependencies from left to right. > Well, if you're going to pick nits: in this case, nothing is broken. > It's known that we're going to use GNU make and that no parallel > execution is taking place. I did not follow these things in years, they might have changed. At some time in the past, GNU packages had to follow GNU standards. We had to write portable Makefiles, could not depend on GNU make, and could not depend on the serial evaluation of dependencies. Many users had things like "MAKEFLAGS=3D-j4" in their environment, so it blindly applied to all their builds. Maintainers would not know that "no parallel execution is taking place", because it was the installers, and not them, to decide. GNU libc has been the first important GNU package which broke the rule and started to require GNU make; it's true that the GNU libc maintainer and the GNU make maintainer were the same guy. I guess that GNU libc was so late that Richard Stallman allowed that exception. Now that Linux exists, it is very frequent to see packages requiring GNU make, and GNU standards are taken much more lightly than they used to be. Looking at the GNU make documentation, I find something new to me: [If] .NOTPARALLEL is mentioned as a target, then this invocation of make will be run serially, even if the =E2=80=98-j=E2=80=99 option is gi= ven. Any recursively invoked make command will still run recipes in parallel (unless its makefile also contains this target). Any prerequisites on this target are ignored. So now, the maintainer may prohibit parallelism from his side, and while I did not see that GNU make explicitly guarantees left to right evaluation and execution, the above says "serially" without telling the order. I would be tempted to think that the GNU make documentation is voluntarily silent on the matter, as we may not depend on it. If you depend on the order, you depend on the implementation of Make, not on its specifications. That's why I use the work "broken". All this is academical, and not much important. For a long while now, the effort for correct Makefiles faded away; this cannot be repaired. Fran=C3=A7ois