Date: Sun, 9 Jun 1996 16:09:47 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: current@FreeBSD.org Subject: Minor nit in build process plus fix Message-ID: <199606092309.QAA03238@phaeton.artisoft.com>
next in thread | raw e-mail | index | archive | help
Hi; My /usr/src is a directory containing a set of symbolic links to the real source locations for various components. This lets me mix-and-match components from multiple source trees pretty much at will using various /usr/src directory configurations. Recently, I had to rebuild ps. The /usr/include directory on my machine is the one from -release. 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 I think this symlink should be in the default /usr/src/sys source tree. There are probably other dependent includes that are handled the same (wrong) way (I haven't hit any, but I'm sure the "net" stuff is in the same boat, etc.). 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. 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. In either case, the relative path dependencies want to disappear so that symlinks can be used; putting printf.c in the "right" place for the dependency (or moving csh to the "right" place) is only a kludge fix. 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?199606092309.QAA03238>