On Thu, 23 Dec 1999, Todd Whitesel wrote:

> Now: how does your cross-compiler find its headers? If it takes _anything_
> from /usr/include then it's going to have problems. We should be compiling
> with "-nostdinc -I$(BSDSRCDIR)/xinclude" and have 'make includes' install
> into $(BSDSRCDIR)/xinclude. $(DESTDIR)/usr/include should get updated at
> 'make install' time, not 'make includes' time.

Actually, gcc/egcs cross compilers are usually configured to look for
includes, by default, in a compiler-specific area. I've forgotten the
path, but it includes both the compiler version, the root (/usr/local/gnu
by default I think), and the target. So you can have a lot of them around
without problem.

By default, the packaged cross compilers don't do this. I think the idea
is that they'd be used to cross-compile the tree, which'd have its own
includes. Thus it wouldn't make sense to have two copies of these includs.

Why should we be using xincludes? I've cross-compiled before, and this is
not a problem. I've cross-built the whole tree with no major changes
needed to the build system (once we added bsd.hostprog.mk).

> (I would have preferred $(BSDSRCDIR)/include, but that's already taken.)
> 
> I believe that when a kernel is updated, no headers should need to change
> (those that do probably shouldn't have been made visible to userland in the
> first place). Building and installing libc & friends will install the new
> interfaces along with the binaries that export them.

Yes, building a new kernel does not need installed headers. 

> Most likely we have some gnarly header dependencies in the current system
> that won't be handled well by this model. I have faith that they can be
> reorganized without unacceptable pain.

The current model works quite fine, or at least did last time I tried. :-)
The only sticky points are when you're cross-compiling from something
other than NetBSD, and helper programs (users of bsd.hostprog.mk) use
NetBSD-specific features.

Take care,

Bill