svn commit: r271771 - in head: bin/csh etc/mail lib/libc usr.bin/grep usr.sbin/mtree

[Bruce Evans]

On Sat, 20 Sep 2014, Julian Elischer wrote:

> On 9/18/14, 10:41 PM, Will Andrews wrote:
>> Author: will
>> Date: Thu Sep 18 14:41:57 2014
>> New Revision: 271771
>> URL: http://svnweb.freebsd.org/changeset/base/271771
>> 
>> Log:
>>    Fix incremental builds involving non-root users with read-only source 
>> files.
>>       Makefiles should not assume that source files can be overwritten. 
>> This is the
>>    common case for Perforce source trees.
>
> I'm concerned that just adding -f may not really be fixing the problem..
> why are the files getting overwritten? I'm not sure forcing an overwrite is 
> teh right answer to read-only sources.

The log message is confused.  Source files are not being overwritten.
They are being copied to object directories using cp.  Then if they
are read-only in the source directory, they are read-only in the object 
directory, even if they are copied without -p so as to clobber their
timestamps (their mode is still preserved).  Then if the source file's
mtime is changed, either by actually changing the file or just by
clobbering its mtime, the copy in the object directory becomes out of
date.  Then the cp to make it up to date fails because it is read-only.

>>   iconv.h: ${.CURDIR}/iconv_stub.h
>> -	cp ${.CURDIR}/iconv_stub.h ${.TARGET}
>> +	cp -f ${.CURDIR}/iconv_stub.h ${.TARGET}
>>   .endif
>>   .endif

Many makefiles avoid this problem by using cat instead of cp to copy
the files.  I prefer using cp -p.  The above fixes the problem for
a makefile that uses cp (without -p) by adding -f.  This causes the file
to be unlinked before a new copy is made.  If the object directory is
in the source tree (most likely since it is the source directory) and
the source files are read-only, then this would often fail because the
source directory is also read-only, but then it can't reasonably be
an object directory.

Bruce