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

[Anthony Towns]

On Mon, Oct 18, 1999 at 11:49:52AM +1000, Ben Carlyle wrote:
> I think the simplest way to state my case is this:
> The parallel execution of command-line targets violates the make
> commands are processed in order. 

Similary, the parallel execution of dependent targets violates the
rule that dependents are processed in order. The real question is
whether this is particularly useful.


> If the parallel make does not
> process the command-line in order, then it has different behaviour
> characteristics to the sequential make.

Similarly, if the parallel make does not process the dependent targets
inorder, then it has different behavioural characteristics to the
sequential make.

> The command-line should
> not specify a list of depedancies, but a list of targets to be
> executed one after the other.

Or, alternately, it should specify a list of goals, all of which have
to be made. If you want to build your system, you should have a single
goal that does just that. If you want to clean your system, you should
have a single goal that does that.

Having a goal `build' that only works when you've already done a `clean',
is broken.

> Executing the command-line parameters in parallel is equivalent
> to adding a rule
> commandline: arg1 arg2 arg3
> to the makefile.
> Executing the command-line parameters sequentially is equivalent
> to adding the rules
> commandline: arg3
> arg3: arg2
> arg2: arg1

Note that both `arg1 arg2 arg3' is much more similar to what you actually
write on the command line.

> It is this second rule that best represents the behaviour of a
> sequential make,

Note that the first rule exactly represents the behaviour of both
sequential and parallel (GNU) make.

> The statement that make
> processes its targets in order must be deleted from all
> documentation, for in fact it executes them in a random order that
> just so happens usually runs from first to last.

Imagine. A bug in the documentation. (Furthermore, I suspect you're
guaranteed to have them started in the order given)
 
> Parallelism should be left to the defined make dependancies, not
> assumed from the commandline.  make clean should run parallel
> clean targets.  make build should run parallel build targets.
> make clean build should run parallel clean targets, then parallel
> build targets.

Nonsense. You should always tell make about *every* dependency in your
build environment. You shouldn't leave it up to chance, or implicit
ordering based on which one you happen to specify first. If your template
libraries depend on every single .c and .h file, you should tell make
that, and have it rebuild them itself when it thinks it needs to.

Personally, I think `make clean' isn't an ideal thing anyway --- make's
good at building stuff, having it destroy stuff too isn't Right. Much
better is the way Aegis (a source control tool, a la CVS) does it: by
having two separate tools: aec (aegis clean) and aeb (aegis build). The
former deletes any files in the source tree that aren't in the repository
(ie, anything that's an object file and any other trash lying around),
and the latter calls make (or an equivalent).

Cheers,
aj, whose HO is very rarely H.

-- 
Anthony Towns <aj at humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.

 ``The thing is: trying to be too generic is EVIL. It's stupid, it 
        results in slower code, and it results in more bugs.''
                                        -- Linus Torvalds
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 434 bytes
Desc: not available
URL: <http://lists.humbug.org.au/pipermail/general/attachments/19991018/4ace0e86/attachment.sig>