David Holland <dholland-tech%netbsd.org@localhost> writes:
> If ${.TARGET} is in the source dir, it should not be doing that at
> all, -f or otherwise... if it isn't, the file shouldn't come out
> unwriteable. Or so I'd think.
The copy is from the source tree to ${OBJDIR}.
My source files are not writable (which I think is a feature).
> Or is the problem that cp is copying to the build tree but inheriting
> the permissions from the source copy? Maybe chmod explicitly after
> copying is a better solution then.
Yes, that is exactly what's happening. The first copy (that happened in
April) succeeded, and one recently did not. None were attempted in the
interim.
chmod would work, if done for the first copy. I picked cp -f because I
thought it existed in other places and fixes the problem when the bad
copy already happened. I can only find it in vax distrib and etc
though.
Alan Barrett <apb%cequrux.com@localhost> writes:
> It might be better for them to use one of the *INSTALL* variables,
> such as ${INSTALL_FILE} or ${HOST_INSTALL_FILE}, or perhape
> BUILDSYMLINKS, depending on the reason for the copy.
INSTALL seems appropriate for copying from OBJDIR (and maybe also
SRCDIR) to DESTDIR.
BUILDSYMLINKS looks like the right approach, and it does:
rm -f ${.TARGET}
ln -s ${.ALLSRC} ${.TARGET}
which is robust against these permission issues.
In share/man/man7/Makefile, I see
rm -f ${.TARGET} && cp ${.ALLSRC} ${.TARGET}
which also seems reasonable, except that it's open coding something that
should be abstracted.
There is also a lot of us of cp in kernel builds, which are odd because
there isn't such a strong objdir/destdir notion for those.
So all in all I lean towards saying "use of cp to put things in objdir
is a bug, and should be BUILDSYMLINKS, unless that won't work, in which
case we need BUILDCOPIES".
Do we have a build style guide? This seems not to belong in
/usr/share/misc/style.
Attachment:
pgpaqC01IEWBh.pgp
Description: PGP signature