From owner-freebsd-current Wed Feb 22 15:43:04 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id PAA10082 for current-outgoing; Wed, 22 Feb 1995 15:43:04 -0800 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id PAA10076 for ; Wed, 22 Feb 1995 15:42:56 -0800 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id QAA15987; Wed, 22 Feb 1995 16:45:52 -0700 Date: Wed, 22 Feb 1995 16:45:52 -0700 From: Nate Williams Message-Id: <199502222345.QAA15987@trout.sri.MT.net> In-Reply-To: Poul-Henning Kamp "Re: TRUE and FALSE" (Feb 22, 3:28pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Poul-Henning Kamp Subject: Re: TRUE and FALSE Cc: wollman@halloran-eldar.lcs.mit.edu, current@freefall.cdrom.com Sender: current-owner@FreeBSD.org Precedence: bulk [ Bring back in the reason that we're doing this ] [ /usr/include/nfs contains .c as well as .h files ] Poul writes: > Since we want (as a medium term goal) to have our source compile > without reference to /usr/include, then we will not need the > links, and we can safely and decisively remove the SHARED!=copies > case. > If you develop kernel-dependent sw, you had better make sure that your > development env is aligned with your kernel, ie something like: > > cd /usr/src/include ; make all install > cd /usr/src/sys ; make all install Garrett responds with: > And I'm saying that it's an incredible imposition to force such > developers to do this every time they make a change to a kernel header > file. I won't stand for it. Nate sez: > I agree with Garrett here. It's silly to do this, and this will cause > no end of problems when people forget to do this after they upgrade > their kernel sources. Forcing a 'make world' every update is much too > anal. Poul answers: > Hang on, you lost an important point here: Anything in the FreeBSD > source will reference the "internal includes", that is relative paths > to the include dirs. Only things like $HOME/hello.c will be at risk... At what gain are we doing this? I believe it's a noble gain to have the source tree compile w/out reference to /usr/include, but what does it gain us? The only thing I can see where it's a big deal is building a brand-new $(DESTDIR) tree. Other than that, most of the time I *want* to use the files in /usr/include and NOT those in /usr/src (speaking as a user-land kind of guy). Also, by no-longer symlinking in the stuff from the current kernel, we add a lot of complexity by requiring a new 'fill in the /usr/include' tree with lots of varying files from /usr/src/sys. Keeping this up to date will be a pain in the butt! Wouldn't it be just easier to separate the include files from the sources files in the kernel? Nate