>>> cd /usr/include
>>> ln -s /sys/sys sys
>>> ln -s /sys/netinet netinet
>>> etc.
>>>
>>> Is there a better way?
>>
>> Yuck ... cd /usr/src/include; make install
>>
>> That should make sure all the includes are up to date and installed
>> correctly.
>
>Actually, I've been thinking that this is also "yuck" for some time.
>
>It would be nice to have a way to do a "make build" (or equivalent steps)
>without having to overwrite your existing "/usr/include" tree with a -current
>tree in order to build a -current kernel/userland.  In other words, the
>existing build is pretty much self-contained within the "/usr/src" tree (or
>wherever you're building from), it would be nice if it was totally
>self-contained.  Of course, I don't know how hard it would be to do this, since
>I'm sure the compiler might want to still search "/usr/include" even if you've
>somehow recursively fed it "-I/usr/src/include".
>
>If I'm running 1.0 (which I am, on a SPARCstation IPC at work) and want to
>risk the waters and try building a -current system, the last thing I want to
>do is overwrite my existing 1.0 include (and/or others) tree so that I can't
>go back to building 1.0-based executables.
>
>(Yes, I know I can save the 1.0 tree to "/usr/include-1.0" or somesuch first,
> and move it back into place later; I was just saying "it would be nice to have
> a way" to do the -current build without having to do such things.)
>
>Is there any hope of doing builds without "cd /usr/src/include; make install"
>first?  (If there isn't, a brief explanation of why is fine.  Thanks.)
>
>	- Greg

Well, actually, one could use "-nostdinc -I/usr/src/include", which removes
/usr/include from the include search path.

Mike B