[comp.bugs.sys5] make - bug or feature?

wescott@sauron.Columbia.NCR.COM (Mike Wescott) (06/16/87)

Why have the implicit (builtin) rules for make changed in SysVr3?
For example the SysVr2v2 (VAX) make's implicit rule for .c~.o is:

		$(GET) $(GFLAGS) -p $< > $*.c
		$(CC) $(CFLAGS) -c $*.c
		-rm -f $*.c

However, the SysVr3 rule is:

		$(GET) $(GFLAGS) $<
		$(CC) $(CFLAGS) -c $*.c
		-rm -f $*.c

The difference being that given a target of zzz/xxx.o and the
existence of zzz/s.xxx.c the SysVr2v2 make does this:

	$ /bin/make zzz/xxx.o
		get  -p zzz/s.xxx.c > zzz/xxx.c
	1.1
	3 lines
	No id keywords (cm7)
		cc -O -c zzz/xxx.c
		rm -f zzz/xxx.c

and you end up with xxx.o in the current working directory and not
as zzz/xxx.o.  Not quite what I asked for, but close.

But the SysVr3 make does this:

	$ newmake zzz/xxx.o
		get  zzz/s.xxx.c
	1.1
	No id keywords (cm7)
	3 lines
		cc -O -c zzz/xxx.c
	0: No source file zzz/xxx.c
	*** Error code 1

	Stop.

Not even close.  xxx.c ends up in the current working directory.  

Which behavior is correct? I suspect that neither is and the rule
(and all the other rules that do get's) should be something like:


.c~.o:
	cd $(<D); $(GET) $(GFLAGS) $(<F)
	cd $(<D); $(CC) $(CFLAGS) -c $(*F).c
	-rm -f $*.c

Ugly.  But it works across directories.


-- 
	-Mike Wescott
	 wescott@ncrcae.Columbia.NCR.COM