[Top][All Lists]

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

RE: make -j and multiple targets

From: Howard Chu
Subject: RE: make -j and multiple targets
Date: Thu, 6 Sep 2001 03:16:28 -0700

> -----Original Message-----
> From: Peter Gammie [mailto:address@hidden

> Howard,

> point taken, patryk told me the same thing. however, it remains that there
> is a nasty interaction between multiple targets and parallel makes.

There are all kinds of new situations to account for when you attempt to run
a make (or anything else, for that matter) in parallel. That is the nature
of the beast. If you write something assuming serial behavior and then try
to execute it in a parallelizing environment, you invariably end up with
something suboptimal, and usually end up with something just plain wrong.
It always takes careful rewriting to get the desired behavior in a parallel

One very common construct that I see in Makefiles looks like this:

all: headers libraries clients servers
  various commands

In a make rule, all the dependencies of a target are supposed to be of equal
"rank". As such, they are all candidates for parallelism. Running a parallel
make on the above construct would fire off jobs to make headers, libraries,
clients, and servers, all at once. This will most likely fail because
the libraries, clients, and servers depend on the headers, and the clients
and servers probably depend on the libraries.

Dependency rules need to truly reflect the dependencies of the situation, in
order to work properly. A carefully written Makefile will behave properly
regardless of serial or parallel execution. The above example should have

all: clients servers

clients: headers libraries

servers: headers libraries

libraries: headers


Another common occurrence in Makefiles is to iterate a set of commands using
shell for loop:

        for i in $(foo); do; \
                make $i; \

This is suboptimal if any of the elements of the loop are independent,
because it
enforces serialization and prevents any possibility of parallelization.
the contents of $foo were all independent, it could just have been written

all: $(foo)


I could write a book on the subject. (Oh wait, I think I already have...)

> > As a side note, it seems odd to me that a script designed to generate a
> > header
> > file needs to append anything to the C source file. Surely anything that
> > needs
> > to be defined should have gone into the header file, and
> #include'd by the C
> > file.
> yes, it's nasty. i grab all the tokens from lexer.l, generate an enum in
> the .h for them, and a token-to-string function in the .c. put it down to
> a phobia about #including files containing code (and also putting code in
> headers).
I guess I can see that. (Of course, I would just use #if/#endif and not
about it.)

> thanks,
> peter

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc

reply via email to

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