[Bram Moolenar]
Hmm, in my POV a rule like:
target: one two three
means that "one", "two" and "three" are build in sequence, not at the
same time. I suppose adding the "-jN" argument changes the semantics of
the Makefile, and that causes it to break.
In fact, so far that I know (and everything I know is debatable! :-),
the "in sequence" is not part of the semantic of Makefiles, and should
never be relied upon. Of course, if you experiment with various "make"
implementations, you may observe that dependencies are usually build in
sequence, but this should be seen as an accident, and not as a proof.
Adding "-jN" does not change the semantics of Makefiles, but it may
uncover bugs in Makefiles. I (and many other maintainers as well) used
to "export MAKEFLAGS=-jN" (with N being a small number) just to make
sure that my (our) Makefiles were not abusing of "make" semantics.
I don't think a parallel build helps much anyway, Vim builds rather fast
(compared to say, OpenOffice, which takes half a day).
Using "-jN" does not usually spare much build time, and this was not the
reason why we used it.
The introduction of A[CM]_MAINTAINER_MODE (in Autoconf then Automake),
to which I much objected, was symptomatic that many maintainers
definitely lost hope (or at least wanted to stop aiming) for perfect
Makefiles. Moreover, "make" is lacking in some areas and might not be
worth salvaging at any price (the mere existence of "aap" tells me that
Bram agrees at least a bit!). As a overall consequence, my starve for
impeccable Makefiles faded, and I do not routinely use "-jN" anymore.
I know, in my view "make" should do everything. Somehow people have
accepted that some part of the building should be done separately, with
the excuse that it's called configuration. Big mistake in my opinion.
I've seen packages configuring on the fly while making. While nice,
this also shows a few drawbacks. Nothing is perfectly black or white.
Prior configuration should be seen as an optimisation issue.
Configuration takes non-negligible time, and we often risk "make"-ing
many times, so it is worth caching configurations results somehow.
Also, separate configuration gives a check point where wrong
configuration decisions may be corrected and retried as necessary.
It is a sad thing, at least for me, that over time, configuration became
so heavy, articulated over many intermediate files, and fine-grained
into so many macros. It much hurts my starve for simplicity. On the
other hand, the multiplication of configuration tools and independent
paradigms would not be a virtue either, because of our limited ability
to learn, for those of us working on many packages at once (even if
admittedly, this is a disappearing trend).
--
François Pinard http://pinard.progiciels-bpi.ca
