From owner-cvs-etc Thu Jun 5 09:10:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA21775 for cvs-etc-outgoing; Thu, 5 Jun 1997 09:10:27 -0700 (PDT) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA21764; Thu, 5 Jun 1997 09:10:20 -0700 (PDT) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.8.5/8.7.3) id JAA20298; Thu, 5 Jun 1997 09:08:38 -0700 (PDT) From: "Rodney W. Grimes" Message-Id: <199706051608.JAA20298@GndRsh.aac.dev.com> Subject: Re: cvs commit: src/etc/mtree BSD.include.dist In-Reply-To: <10588.865472291@time.cdrom.com> from "Jordan K. Hubbard" at "Jun 4, 97 05:58:11 pm" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 5 Jun 1997 09:08:38 -0700 (PDT) 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 X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-cvs-etc@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > 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