Date: Fri, 19 Sep 1997 11:38:36 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com> To: asami@cs.berkeley.edu (Satoshi Asami) Cc: gurney_j@resnet.uoregon.edu, dima@tejblum.dnttm.rssi.ru, freebsd-current@FreeBSD.ORG Subject: Re: Yet Another bug in src/Makefile Message-ID: <199709191838.LAA11204@GndRsh.aac.dev.com> In-Reply-To: <199709190643.XAA10791@silvia.HIP.Berkeley.EDU> from Satoshi Asami at "Sep 18, 97 11:43:20 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> * why should it remove /usr/include?? /usr/include is not used for the
> * building of the resulting binaries install.. why not do a rm -rf /
> * if you want to clean out the area your installing to... :)
> *
> * of course there is good argument that the installed to area should
> * be clean to prevent old files from contaminating a setup... but
> * if we start to clean out /usr/include, we should also do /{bin,sbin}
> * /usr/{bin,share,sbin,lib,libexec} and any others that get installed...
>
> I agree with you, but the comments at the top of src/Makefile say
> otherwise. Should we just nuke the CLOBBER option entirely, or change
> the rules so it will actually delete /usr/include/*?
>
CHANGE THE RULES. This was done to remove old cruft that the current
source tree knows nothing about from /usr/include. The only way to
insure that is to remove it all and install into a clean tree.
For example if my FreeBSD 1.1 had some header installed in /usr/include
that is not even known to FreeBSD 2.2 it would get left behind now
by a make -DCLOBBER world. The whole reason that CLOBBER existed was
to make sure that /usr/lib and /usr/include don't have old stuff left
around in them.
See other mail for added section to installworld: target.
--
Rod Grimes rgrimes@gndrsh.aac.dev.com
Accurate Automation, Inc. Reliable computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709191838.LAA11204>