From owner-freebsd-current  Wed Feb 22 18:22:50 1995
Return-Path: current-owner
Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id SAA14755 for current-outgoing; Wed, 22 Feb 1995 18:22:50 -0800
Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id SAA14746; Wed, 22 Feb 1995 18:22:38 -0800
Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id SAA26107; Wed, 22 Feb 1995 18:21:40 -0800
From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>
Message-Id: <199502230221.SAA26107@gndrsh.aac.dev.com>
Subject: Re: TRUE and FALSE
To: jkh@freefall.cdrom.com (Jordan K. Hubbard)
Date: Wed, 22 Feb 1995 18:21:39 -0800 (PST)
Cc: current@freefall.cdrom.com
In-Reply-To: <5415.793490429@freefall.cdrom.com> from "Jordan K. Hubbard" at Feb 22, 95 02:00:29 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 2269      
Sender: current-owner@FreeBSD.org
Precedence: bulk

> 
> > > And that seems a little silly (so is exporting the entire NFS tree into
> > > /usr/include, while we're talking about silly, but that's another diatribe
> > > entirely).
> > 
> > Hello, Jordan?  Wake up!
> > 
> > wollman@khavrinen(11)$ ls -l /usr/include/nfs
> > lrwxr-xr-x  1 bin  bin  8 Feb 21 15:03 /usr/include/nfs@ -> /sys/nfs
> 
> Thank you, Garrett.  However, you complelely and utterly missed my point.
> 
> When I said "exported" I meant exactly that: One way or another we
> have now /usr/include/nfs/* containing the full NFS sources rather
> than just the relevant header files.  If you're any kind of purist at
> all, this is immediately obvious as being rather evil.  If I wanted to
> move my header files from one place to another I could easily be
> forgiven for wanting to simply tar up the contents of /usr/include and
> get ONLY the header files (rather than a pastiche' of links, files,
> sources and god-only-knows-what).
> 
> To put it another way, the /usr/include directory follows NO
> consistent paradigm - some things are links, others are copies of
> stuff, still others are just pointers into the sources.  If you make
> with SHARED=copies then this unifies some of it by copying stuff
> across, but it could then be argued that the "non-copies" case should
> see /usr/include as *only* a link farm, with no actual files in there.
> 
> Am I the only one who sees this as somewhat inconsistent?

This will be fixed some time around 2.2, the current SHARED=copies only
has these links:
test:rgrimes {111} find . -type l
./errno.h
./fcntl.h
./syslog.h
./termios.h
./float.h
./floatingpoint.h
./stdarg.h
./varargs.h
./nterm.h

And all of those links resolve to files within /usr/include, all of
them pointing into /usr/include/machine/ and /usr/include/sys.  These links
will remain forever as far as I can see.

My revamped .mk stuff that is sitting on hold for quite some time has
mechanisms in it to fix the SHARED=symlink case by making ALL of /usr/include
symbolic links.  I do not see me getting back to this stuff for 2.1, but
should get back to it for 2.2.

> 					Jordan

-- 
Rod Grimes                                      rgrimes@gndrsh.aac.dev.com
Accurate Automation Company                   Custom computers for FreeBSD