RE: make -j and multiple targets

[Howard Chu]

> -----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
environment.

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
obviously
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
been

all: clients servers

clients: headers libraries

servers: headers libraries

libraries: headers

etc...

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

all:
        for i in $(foo); do; \
                make $i; \
      done

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

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
worry
about it.)

> thanks,
> peter
>

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