Make vs. source control

[Kim Walden]

In article <cyb-eng.425> howard at cyb-eng.UUCP (Howard Johnson) writes:
>[munch]
>>	The problem of overwriting source files if the SCCS parent file
>>	was modified can be helped a great deal by changing the $(GET) lines
>>	in rules.c from:
>>
>>	"\t$(GET) $(GFLAGS) -p $< > $*.c",
>>
>>	to:
>>
>>	"\t$(GET) $(GFLAGS) $<",
>>
>>	and let 'get' check if the file is writable. I have done this and
>>	prefer it to the original.
>
>The only problem with this suggestion is that $*.c is not necessarily in the
>current directory, and 'get' places it's g-file in the current directory.
>I'll admit that the first construct is dangerous, but there may be a better
>fix for the problem:
>
>	"\ttest -w $*.c || $(GET) $(GFLAGS) -p $< > $*.c",


The standard System V built-in make rules for getting files from SCCS
are certainly erroneous, but none of the replacements suggested
so far are adequate. 
The command line above does not work for two reasons:

	1. When $*.c already exists and is read-only, the > will fail.

	2. When the $(GET) succeeds it leaves $*.c writable, which
	   is not what we want. A subsequent "get -e" then fails with
	   "writable 'file' exists".

By the way, it is very dangerous to checkout changes to built-in make
rules in superuser mode, because write permission is then silently
granted even when all write bits are off.

The following rule type seems to solve the problems:
(the leading '-' prevents a premature make exit):

".c~.c:",
"\t-test -w $@ || { rm -f $@ ; $(GET) $(GFLAGS) -p $< > $@ ; chmod 444 $@ ; }"


Note that in multi-step rules, where g-files are obtained, processed,
and removed, a simple get is sufficient, e.g.:

".c~:",
"\t$(GET) $(GFLAGS) -p $< > $*.c",
"\t$(CC) $(CFLAGS) $*.c $(LDFLAGS) -n -o $@",
"\t-rm -f $*.c"

			Kim Walden
			ENEA DATA, Sweden
			...decvax!mcvax!enea!kim