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

Ben Carlyle benc at foxboro.com.au
Fri Oct 15 03:18:52 EDT 1999


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

Good afternoon Humbuggers,

Does anyone have experience of the behaviour of gnu make when targets
are listed on the command line?

I have been playing with version 3.78.1 of gnu make, the lastest
available at my download site.  I have already made a small
modification to suit my purposes here at Foxboro whereby the
timestamps of successive symbolic links are examed as it falls
down the chain.

My problem is to do with the way it handles a combination of the
-j option and multiple command-line targets, in which case it
simply runs the command-line targets in parallel.
I believe this is not the correct behaviour, but I thought I'd
throw it to a wider audience before going too much further with
it.

Here is an example:
--- Makefile ---
OBJS = a b c d e f g h
 
${OBJS}:
        sleep 1; \
        touch $@
--- end Makefile ---

Here is my make output for gnu make version 3.78.1

--- output ---
beast:mtradm-/home/mtradm/fiddling> rm -f a b c d e f g h; time gnu_make
-r -j10  a b c d e f g h                 
sleep 1; \
touch a
sleep 1; \
touch b
sleep 1; \
touch c
sleep 1; \
touch d
sleep 1; \
touch e
sleep 1; \
touch f
sleep 1; \
touch g
sleep 1; \
touch h
 
real    0m1.12s
user    0m0.07s
sys     0m0.26s
--- end output ---

This occurs with both the raw make source and my doctored version.
It seems to me this would also cause problems for Byron's favourite
kernel compile command (and mine).

--- Aside ---
If you find that your make version has this problem, you can
achieve a similar kernel compile (with error checking) using
the following command:
make dep && make clean && make bzImage && make modules && make
modules_install

Byron Ellacott wrote:
> (also note using ``make dep clean bzImage modules modules_install'' is
> healthier, since it doesn't continue blithely on if there is an error in a
> previous make)
-- end Aside ---


So I guess what I'm really asking is this:
Is this normal, or is it a problem with the new make version?
Should I go back and doctor something earlier?
I would like to use this or a later version if possible, as it
has some nice interfaces to distributed builds.  If this doctored
version is going to compete on a level playing field with our
current make system then it will have to support distributed
processing at some time in the future.  Apart from distributed
processing, I have pretty much achieved the same results I was
getting from the old system with an order of magnitude speed increase,
however this command-line problem is quite significant to me.
If this is a genuine bug, is anyone on this list aware of current
fixes that I might not be?


Benjamin.

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



More information about the General mailing list