Date: Sun, 9 Jun 1996 19:52:47 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bde@zeta.org.au (Bruce Evans) Cc: current@FreeBSD.org, terry@lambert.org Subject: Re: Minor nit in build process plus fix Message-ID: <199606100252.TAA02819@phaeton.artisoft.com> In-Reply-To: <199606100134.LAA23798@godzilla.zeta.org.au> from "Bruce Evans" at Jun 10, 96 11:34:59 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >The ps build builds a -I/sys include line, but since there is no > >/sys/machine, it finds the correct /usr/include/sys directory, > >but gets the old /usr/include/machine directory. > > >There is a fix: > > > ln -s i386/include /sys/machine > > Better fix: remove `CFLAGS+=-I/sys' from ps/Makefile. Then whatever > method you use to get the correct /usr/include/sys/* will work. The > easiest method is for /usr/include/sys to be a symlink to /sys/sys. > This is the default except in releases. /sys is wrong too (because > only root can change it, and it can only point to one place at a time), > but it's simpler than a maze of symlinks and -I options. I want to build some portions of the tree with new code, and some with release code. The /usr/include/sys *CAN NOT* point at the kernel /sys directory... basically for anything other than the contents of /bin or the kernel build itself. I guess the real problem there is that installed headers are used at all in any build. Really, I want to be able to build pieces that are dependent on the kernel includes seperately from those which aren't. I suppose that ideally, ps would reference /proc instead of /dev/mem, then I could twiddle the size of the proc struct until I was blue in the face without breaking it. > >The reason this is an issue is that the ps command includes sys/proc.h > >which includes files from the machine include directory, and while > >the sys directory is correctly redirected to the current /sys's > >includes, the machine directory is not. > > Almost all headers in /usr/include include at least <machine/ansi.h> > from the machine directory, so mixing versions may break things. I want to mix versions, but not break things. 8-). More accurately, I want to modularize so I can decide to do a minimal build, leaving everything else to run in binary compatability for previous releases. It's recognized that "ps" and "w" are kernel dependent, whereas "ls" and "more" are not. I'd rather not build "more" if I'm building to hack kernel code. > >I would also like to see relative path dependencies disappear. The > >/bin/csh relative path dependency on usr.bin/printf is especially > >annoying, given the relative prioritization of the bin and usr/bin > >directories in a live system. > > Relative paths are used to avoid the problems with absolute paths :-]. > usr.bin/printf is slightly less likely to be in the usual absolute > place than in the usual relative place. I was thinking in terms of the top level make setting an environment variable. The problem is really "..", not "paths relative to the build root". The other issue here is the ability to build multiple shared library versions (which the library include file for make tends to damage beyond recognition). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606100252.TAA02819>