From owner-freebsd-current Fri Sep 19 07:41:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA15862 for current-outgoing; Fri, 19 Sep 1997 07:41:57 -0700 (PDT) Received: from usr07.primenet.com (tlambert@usr07.primenet.com [206.165.6.207]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA15857 for ; Fri, 19 Sep 1997 07:41:53 -0700 (PDT) Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id HAA05896; Fri, 19 Sep 1997 07:41:17 -0700 (MST) From: Terry Lambert Message-Id: <199709191441.HAA05896@usr07.primenet.com> Subject: Re: Yet Another bug in src/Makefile To: asami@cs.berkeley.edu (Satoshi Asami) Date: Fri, 19 Sep 1997 14:41:17 +0000 (GMT) Cc: tlambert@primenet.com, gurney_j@resnet.uoregon.edu, dima@tejblum.dnttm.rssi.ru, freebsd-current@freebsd.org In-Reply-To: <199709190641.XAA10786@silvia.HIP.Berkeley.EDU> from "Satoshi Asami" at Sep 18, 97 11:41:06 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > * There are other builds which also reference out of the build tree; > * anything which references or , in particular, > * references /usr/include. A reference to can't be > * resolved without /usr/include/ since it refers to the postinstalled > * headers from /usr/src/sys/i386/include/ into /usr/include/machine/. > * The , , <*fs/*>, , and references are > * all in this boat, as well as others from package/base installation > * (, etc.), if installed. > > Terry, you have absolutely no idea what you're talking about. It's > amazing how you could miss every single one of the discussions on this > topic in -current, -stable, -hackers and -committers in the past few > months. I am not talking about ports. Feel free to tell me how, other than making changes to the default arrangement of files, I can build multiple kernel environments. I tend to build a lot of kernel environments, and that means rebuilding libkvm, w, ps, who, netstat, arp, ifconfig, mount, mount_*, and a grundle of other things which depend on kernel "interfaces" exported through /dev/kmem. In order to do this, I have to change the way the build works locally, starting with a lot of symbolic links (which I documented in the discussion you are referencing), but not only symbolic links. I do not *want* to do a "build world" in order to do this. I am *only* changing my kernel, and I want to *only* change things that depend on my kernel (and there are too many of those to suit me, too). I do not want to change out the majority of my build environment for standard programs which are not affected by kernel changes. I sure as hell do not want to rebuild "more", or even do a make install in /usr/src/include. I want to buildd the *absolute* minimum for the delta I am playing with -- and not *one file* more or less than that. I find it really surprising that you can in any way believe a reference to a file can be in any way satisfied by the contents of /usr/src/sys/i386/include, save for me doing a rebuild of my /usr/include directory. Even if I were to do a "-I/usr/src/sys/i386/include" on the compilation command line, it would do me no good: there is no subdirectory named "machine" where the *right* include files may be found. Now you may argue, as I did, that you can create a symlink tree in /usr/include in order to deal with this, one of which would be: ln -s /sys/i386/include /usr/include/machine However, this fails to account for cross-build environments for things like the DEC Alpha and the HP345, which though they do not yet run a pure FreeBSD kernel, can nevertheless be cross-built on a suitably munged-away-from-the-supposedly-correct-defaults FreeBSD system. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.