svn commit: r271771 - in head: bin/csh etc/mail lib/libc usr.bin/grep usr.sbin/mtree
Will Andrews
will at firepipe.net
Mon Sep 22 16:04:21 UTC 2014
On Sat, Sep 20, 2014 at 1:38 AM, Bruce Evans <brde at optusnet.com.au> wrote:
> 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.
Yes, this is the more correct way of explaining the issue. Thanks.
> 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.
The problem with 'cp -p' is that it doesn't work either. Try it
(twice) with a read-only file -- I get EPERM when I try the second
time. cp -p also doesn't work with NFS targets if the file happens to
have flags.
In the case of .CURDIR == .OBJDIR, the file would satisfy the
dependency and thus not be overwritten with itself. In any case, this
is about read-only *files* anyway, not read-only directories, since as
you point out, the latter are unusable as object directories.
--Will.
More information about the svn-src-all
mailing list