From: "François Pinard" <pinard@iro.umontreal.ca>
To: emacs-orgmode@gnu.org
Subject: Re: Reloading uncompiled and testing from several git branches
Date: Mon, 18 Feb 2013 20:17:49 -0500 [thread overview]
Message-ID: <86wqu55cg2.fsf@iro.umontreal.ca> (raw)
In-Reply-To: <87lial5t4r.fsf@Rainer.invalid> (Achim Gratz's message of "Mon, 18 Feb 2013 20:17:24 +0100")
Achim Gratz <Stromeko@nexgo.de> writes:
> François 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=-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 ‘-j’ option is given. 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çois
next prev parent reply other threads:[~2013-02-19 1:17 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-28 20:19 Macro question with new texinfo exporter Thomas S. Dye
2013-01-29 18:21 ` Nicolas Goaziou
2013-01-29 18:49 ` Thomas S. Dye
2013-01-30 9:22 ` Bastien
2013-01-30 12:44 ` Nicolas Goaziou
2013-01-30 16:14 ` Bastien
2013-01-30 22:24 ` Nicolas Goaziou
2013-01-31 2:21 ` Thomas S. Dye
2013-01-31 13:51 ` Bastien
2013-01-31 13:58 ` Nicolas Goaziou
2013-01-31 21:23 ` Nicolas Goaziou
2013-02-04 15:43 ` Thomas S. Dye
2013-02-04 17:26 ` Bastien
2013-02-04 18:57 ` Achim Gratz
2013-02-16 9:21 ` Bastien
2013-02-16 10:19 ` Achim Gratz
2013-02-16 10:34 ` Bastien
2013-02-16 10:39 ` Achim Gratz
2013-02-16 13:18 ` Eric Abrahamsen
2013-02-16 13:23 ` Reloading uncompiled and testing from several git branches (was: Macro question with new texinfo exporter) Bastien
2013-02-16 14:10 ` Reloading uncompiled and testing from several git branches Achim Gratz
2013-02-16 14:21 ` Bastien
2013-02-16 14:59 ` Eric Abrahamsen
2013-02-17 0:08 ` François Pinard
2013-02-18 12:57 ` Nicolas Richard
2013-02-18 19:17 ` Achim Gratz
2013-02-19 1:17 ` François Pinard [this message]
2013-02-16 16:40 ` Macro question with new texinfo exporter Nick Dokos
2013-02-16 16:47 ` Nick Dokos
2013-02-16 16:19 ` Nick Dokos
2013-02-16 17:37 ` Thomas S. Dye
2013-02-04 18:10 ` Nicolas Goaziou
2013-02-04 18:48 ` Thomas S. Dye
2013-02-04 18:38 ` Achim Gratz
2013-02-04 20:21 ` Thomas S. Dye
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86wqu55cg2.fsf@iro.umontreal.ca \
--to=pinard@iro.umontreal.ca \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).