[H-GEN] gnu make command-line target ordering problems?

[Ben Carlyle]

[ Humbug *General* list - semi-serious discussions about Humbug and
Unix-related topics. ]

Martin,

The primary reason why I think it is not reasonable[1] is that this
make behaviour is not compatable with the sun-style behaviour,
which executes each target sequentially with permission within the
generation of each target to execute in parallel[2].

The secondary reason why I think it is not reasonable is this quote
from http://www.dsv.su.se/comp/docs/make_81.html#SEC80.
``You can specify a different goal or goals with arguments to make. Use
the name of the goal as an argument. If you
specify several goals, make processes each of them in turn, in the order
you name them.[3]''  (a document co-written by Richard M. Stallman and
Roland McGrath)

Finally, the source code it's self appears to support the single
execution quite nicely.  I have not had a chance to test my little
hack as extensively as I want to, but it appears that by breaking
up the goals list into bite-sized chunks for the update goal
function one can achieve the same results as sun make.  It is,
however, a shame to do that as it looks like someone has put a
fair bit of work into making it execute so nicely in parallel.

I'm afraid I can't reference any posix or other standards on this
issue.  I don't have acess to them.  I'm quite sure I'm being
unreasonable about this... it's just that it messes up my makefiles
to have to execute the makes sequentially in shell scripts :)

My problems stem from the two issues of makefile extensibility using
a global rule-set, and that of *censored* sun C++ template handling.
*censored* sun C++ template handling is based on the idea of a template
library for each source directory. It is *censored* not good at
determining when templates have to be reinstantiated into this library,
hence the *censored* library has to be *censored* cleaned out before
any source is *censored* built.  Afterwards, problems in our design
compound this problem in that we have quite a large set of overlapping
templates.  They are shipped out to a central processing area to be
combined into a single library, and this has to be done after the
source is built.  This combination is quite difficult to deal with
sensibly, and similar kinds of problems crop up all over our system.
Using the "make pre.source do.source post.source" is a simple hack
I have used to deal with such conditions.  Naturally with a better
program design and better tools the need for this kind of hackery
would be reduced... but there are certainly times when I need to
make use of serial execution.

My position at this point is that normal developers will, by default,
execute their comands sequentially.  The speed improvements of gnu
make are significant enough to make this quite acceptable.  Parallel
makes will be reserved for my own full builds, which will take place
with a little more control.  When I have fully tested my serialisation
extension to gnu make I will let developers use it again, as it will
then behave in a intuitavely compatable fashion to the sequential
build.


Benjamin.

[1] or rather I think it is darn inconvenient, counter-intuitive and
    incompatable.
[2] eg "make clean build" would execute the "clean" phony target
    dependancies in parallel, then wait, then execute the "build"
    phoney target dependancies in parallel.
[3] which it does, however this statement has little or no meaning
    to gnu make when parallel execution is selected.


Martin Pool wrote:

> I'm not sure why you think this is not reasonable:
>   make a.a b.b c.c    # means "make a.a and b.b and c.c"
> is really not the same as
>   make a.a && make b.b && make c.c  # "make a.a then b.b then c.c"

--
This is list (humbug) general handled by majordomo at lists.humbug.org.au .
Postings only from subscribed addresses of lists general or general-post.