Date: Thu, 5 Jun 1997 09:08:38 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: msmith@atrad.adelaide.edu.au, ache@nagual.pp.ru, asami@cs.berkeley.edu, bde@zeta.org.au, cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-etc@FreeBSD.ORG Subject: Re: cvs commit: src/etc/mtree BSD.include.dist Message-ID: <199706051608.JAA20298@GndRsh.aac.dev.com> In-Reply-To: <10588.865472291@time.cdrom.com> from "Jordan K. Hubbard" at "Jun 4, 97 05:58:11 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > OK, so we expect to see a new makefile rule at the top level of the
> > kernel source tree that will copy all the includes to the relevant
> > places under /usr/include?
>
> Yeah. It's called "make includes" :-)
>
> Seriously, with SHARED=copies as the default and a couple of anomalies
> like /usr/include/ufs cleaned up, it works pretty well right now.
>
> Jordan
Since I was the one who turned on SHARED=copies and fixed it up to
do the right things way back in the 1.X days for releases I feel I
need to say a few things about why it _is_ a good idea in support
of Jordan here, though I won't go so far as to support ripping
out the SHARED knob.
1) The reason it was turned on at all was so that a binary distribution
would include a complete /usr/include tree so that the compiler(s)
could find them without needing a /sys tree. In the 386BSD days
Bill shipped the system with SHARED=symlinks (the Berkeley default
as far back as I can remember) and it was a FAQ on the list that
you ``need to install the src distribution to be able to compile
programs'' (at that time the sources where all in 1 distribution
pack, some 15 odd floppies if I recall correctly.)
2) /usr/include containes the interface to the currently running
/usr/lib and /kernel, _not_ to the current contents of /usr/src.
/usr/include should be updated when things are installed from
/usr/src into /usr/lib or a new kernel is installed. Not one
second before, as doing so causes a potential miss match
in API's.
3) Some day /usr/src is not going to depend on /usr/include, the
opposite should be true, and can easily be done today with
the correct setting of SHARED=copies.
4) I've been running my *BSD systems for 5 years with SHARED=copies
and have had no problems. Also all of the systems I build and
ship have been setup that way and I have yet to here a customer
have a problem with it.
5) On a multideveloper machine you do not want one developers
current edits to /usr/src/sys/param.h that are not in /kernel
to effect the compilation of some user land program. (ooppss..
guess this is the same things as 2 above).
6) There are still many actual files installed in /usr/include
when SHARED=symlinks, not all /usr/src changes are instantly
propogated to /usr/include. This is an inconsistent nightmare IMHO.
Now, the reason to leave the SHARED knob in (ie, I am just advocating
changing the default from symlinks to copies, until such time as
/usr/src stops depending on /usr/include, at which time the knob
can be ripped out since it would then be pointless.)
1) A developer working on a kernel/userland interface issue can
easily save some time buy running with the symlinks. A
change in a kernel header file is instantly avaliable to
test compile the userland utility.
--
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?199706051608.JAA20298>