Re: Linus's include file strategy redux

["Dana Lacoste" <dana.lacoste@peregrine.com>]

> On Fri, Dec 15, 2000 at 12:14:04AM +0000, Miquel van Smoorenburg wrote:

> It's the version that's in cvs, I just did an cvs update.  It's
> been in it for ages.  If it's wrong, someone *please* correct it.

I think this is the important part.
This subject has come up quite a few times in the past
couple of weeks on the scyld (eepro/tulip) mailing lists.

Essentially, whatever solution is implemented MUST ensure :

1 - glibc will work properly (the headers in /usr/include/* don't
    change in an incompatible manner)

2 - programs that need to compile against the current kernel MUST
    be able to do so in a quasi-predictable manner.

Here's some suggestions (feel free to hack this to pieces, but please
don't let this fall to the side with everyone doing it differently!
we need consensus! :)

- /usr/include/[linux|asm] will be directories, not symlinks, and
  their content will be the headers that glibc was compiled against.

- /usr/include/kernel will be a symlink to the target kernel headers.
  i.e. /usr/src/linux/include for most of us.

This way, anything that needs to use the 'default' methods of accessing
these headers will be able to function as usual, and anyone who needs
to access the specific kernel headers can simply do -I/usr/include/kernel

I know that for my projects this is essentially what I do : I make sure that
all of my separate-from-kernel compiling that needs to be done that depends
on the kernel gets recompiled every time i change the kernel,
but I only change /usr/include/linux when I recompile glibc.

We really need a documented way to deal with this!
It's getting silly the number of questions that people ask!

--
Dana Lacoste
Linux Developer
Peregrine Systems

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/