kevin@nuchat.UUCP (Kevin Brown) (12/16/90)
I hope this hasn't already been hashed out ad infinitum...
I've been having some "problems" with the make program that comes with Minix
1.5, and was wondering if anyone has fixed the following "bug":
Suppose you have the following makefile:
# makefile begins here
CC = cc
cswitch = -c
extra = -DDEBUG
OBJS = tmp1.o tmp2.o
c.o :
$(CC) $(cswitch) $*.c
tmp: $(OBJS)
$(CC) $(ldswitch) $(OBJS)
tmp1.o : tmp1.c
tmp2.o : tmp2.c
$(CC) $(cswitch) $(extra) $*.c
#makefile ends here
The make program that comes with IBM Minix 1.5.10 from P-H will execute the
following:
cc -c tmp1.c
cc -c -DDEBUG .c <--- This is WRONG! ".c" should be "tmp2.c"...
cc tmp1.o tmp2.o <--- now it can't link properly because tmp2.o
wasn't built!
To be more specific, the macros $* and $< are always NULL in a dependency-
specific command, e.g. the one for the dependency "tmp2.o : tmp2.c".
There is a command-line switch, -a, which will cause make to "try to guess
undefined ambiguous macros (*,<)". Using this switch will cause make to
behave properly in the above case.
The problem, of course, is that there should be nothing "ambiguous" about
what the values of those macros should be!
I have kludged "make" such that -a will now turn OFF the "guessing" on the part
of make, so "guessing" is now the default. This causes it to work properly
for makefiles like the one included with the zoo distribution. I haven't
tested it very much, so I don't know whether there will be any strange
behavior as a result of, effectively, doing a "make -a" (old definition of
-a) by default.
I have tracked down the errant behavior (if it is indeed errant) to the
routine dyndep(), in rules.c, which determines dynamic dependencies.
Unfortunately, it seems to check only built-in rules, so rules that are
specified explicitly (as in the above example) for a given dependency are not
treated properly.
The code for much of make is rather sparsely commented and is a bit
difficult to read. It will take me some time to figure out exactly what
they're doing, and what to do to correct the above problem. Before I go
to all that trouble, however, I wanted to ask: has anyone already fixed
this problem? Or did everyone just hack it the way I did? :-)
For those who are interested, I'm running Minix 1.5.10 with Bruce's
386 patches. The fact that I'm running in 386 mode makes no difference,
however. Make screws up the same way in its original form.
As an aside, it is interesting to note here that the make included with
Minix is essential for use with Bruce's makelib script. Or, at least
gnu-make (the binary available on plains) will not behave properly with
Bruce's makelib script. It doesn't seem to be an inappropriate command
line switch, unless gnu-make doesn't understand the -f switch!
In case anyone's interested, here's the kludge for causing Minix make to
work right in the case I cited above. Use at your own risk. :-)
---------------------- Cut here ------------------------------
table
!"#$%&'()*+,-./0123456789:;<=>?
@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_
begin 644 make.patch.Z
M'YV-*@*">%%GCIP7!L>\&/.F39LP;LC,>?%P31F*8=*X<3$FP94R9$ \&4,'z
M1 P8(&#,T*%2QPP<)G/D@*&@A4T0#S5R3#"ECAL01,J,,6DC)0T=,FRP1!E#y
M)LV 4*-*5:$ *@@9-%@D!1%5 8BO5$. 3= B# @Z<O*<?0/B3)TR<^: \$FFx
MC!F-($&$:2,FC=LW!7&&&2/GC5P4*ECP2.%U;(N0<.1H+%E73)TS9S2> :'1w
MS)N:-[%JO0'"ILW&7!6(Y4K6[)PR)>O $4S8, C$BE.L!7'GC9PU(-ZX8:/6v
MLQP0D4':Q1M23ATV<%F </.FI&JP7[-K-\XY8AH[:<C4"<,FN!NX+E"K( M9u
MLAO*92QCUMS=<]6I^*E:Q8I#:PV477V5P!AAO ;""6&<H,-U"22P5U]G/#14t
M#R!0(4451>S06(-BR%%&&&MH:-I5-.3@7PREF;8A@08BJ""##O+EEX0@4&A$s
M$$Q,D>&&"73X88CWJ3!000<EM%!##T4T4447H>$"&A[E-5)))Z6T4DLSD-;4r
M3*"U (*34/;T4U!#Q5 4#$<EM51,7.:'7Y!7R0"#5C+(P!54C16!!15%2.$$q
M"&*\\49Y() A1F9N>/95$DXD004*-^981 H[#"0D"%"X5Q(;U05G1J'Q78;Hp
M9IWY]A =:0C'U0O7Z<FGGX *2NB#,PX& J..0HJCCI1:^I5;<,E%EUTNZ"7Co
M7X%)6-AAB2VV:IY[]OGG'&C50=)T>Y4!UEUR4.M&MB*&)B>==IK6 K2O_AGHn
MH%\9BJBBMS;Z:*2\5OK"I9E.!@*G);WQ:66BTE>J'*>F^I,*K(KEJK2QLFLLm
MA#3B^JB%&/;J:UMOQ3571,0^[%<=@,FEK&VX.8LPN@Q3Z]RUW[:A+5?<>@NNl
! C3Bk
j
end
--
Kevin Brown
Addresses in preferred order:
csci31f7@cl.uh.edu
nuchat!kevin@uunet.uu.net