> 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.

Yes, but those are installed during 'make install' for the cross compilers.
After the next supscan, they become out-of-date, so either we must update
them as part of the cross-build process or use something else.

> 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.

Right, and my proposed place for "its own includes" is 'xincludes'.

> 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).

For a single cross build, sure, but how about tracking -current over time?
How often do you regenerate the cross compilers (thus updating the installed
headers) ?  This becomes almost a non-issue if your standard procedure is to
regenerate before every build.

The basic benefit of xincludes is that it allows 'make includes' to work
without jeopardizing /usr/includes until 'make install' time. In the case
of cross builds, it supplies the headers so the cross-compiler doesn't have
to worry about providing headers and keeping them in sync with the source
tree.

Todd Whitesel
toddpw @ best.com