[net.unix] Make vs. source control

howard@cyb-eng.UUCP (Howard Johnson) (10/27/84)

[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",

>>	Wednesday:  Source Administrator makes global
>>		change to headers of all project source
>>		files.
>>	Thursday: Programmer `make's a new version
>>		and wipes out two day's work.

It could be noted that this problem may not have occurred if the source
administrator had communicated with the person who had the file out for
editing (look for p-files) and the programmer keeps a local copy of
files he edits for which he hasn't used 'get -e'.

	Howard Johnson	..!ut-sally!cyb-eng!howard

kim@enea.UUCP (Kim Walden) (11/02/84)

In article <cyb-eng.425> howard@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