From: "LA Walsh" <law@sgi.com>
To: "Alexander Viro" <viro@math.psu.edu>
Cc: "lkml" <linux-kernel@vger.kernel.org>
Subject: RE: Linus's include file strategy redux
Date: Thu, 14 Dec 2000 23:21:31 -0800 [thread overview]
Message-ID: <NBBBJGOOMDFADJDGDCPHCENKCJAA.law@sgi.com> (raw)
In-Reply-To: <Pine.GSO.4.21.0012141900140.10441-100000@weyl.math.psu.edu>
> Huh?
> % ls -ld /usr/include/linux
> drwxr-xr-x 6 root root 18432 Sep 2 22:35
> /usr/include/linux/
>
> > So if we create a separate /usr/src/linux/include/kernel dir, does that
> > imply that we'll have a 2nd link:
>
> What 2nd link? There should be _no_ links from /usr/include to the
> kernel tree. Period. Case closed.
---
> ll -d /usr/include/linux
lrwxrwxrwx 1 root root 26 Dec 25 1999 /usr/include/linux ->
../src/linux/include/linux/
---
I've seen this setup on RH, SuSE and Mandrake systems. I thought
this was somehow normal practice?
> Stuff in /usr/include is private libc copy extracted from some kernel
> version. Which may have _nothing_ to the kernel you are developing for.
> In the situation above they should have
> -I<wherever_the_tree_lives>/include
> in CFLAGS. Always had to. No links, no pain in ass, no interference with
> userland compiles.
>
> IOW, let them fix their Makefiles.
---
Why would Linus want two separate directories -- one for 'kernel-only'
include files and one for kernel files that may be included in user
land? It seems to me, if /usr/include/linux was normally a separate
directory there would be no need for him to mention a desire to create
a separate kernel-only include directory, so my assumption was the
linked behavior was somehow 'normal'.
I think many source packages only use "-I /usr/include" and
make no provision for compiling against kernel header files in
different locations that need to be entered by hand. It is difficult
to create an automatic package regeneration mechanism like RPM if such
details need to be entered for each package.
So what you seem to be saying, if I may rephrase, is that
the idea of automatic package generation for some given kernel is
impractical because users should be expected to edit each package
makefile for their own setup with no expectation from the packages
designers of a standard kernel include location?
I'm not convinced this is a desirable goal.
:-/
-linda
-
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/
next prev parent reply other threads:[~2000-12-15 7:53 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <91gr99$bs81o$1@fido.engr.sgi.com>
2000-12-14 23:55 ` Linus's include file strategy redux LA Walsh
2000-12-15 0:14 ` Miquel van Smoorenburg
2000-12-15 0:17 ` Alexander Viro
2000-12-15 0:39 ` Miquel van Smoorenburg
2000-12-15 0:33 ` Alan Cox
2000-12-15 0:48 ` Alexander Viro
2000-12-15 0:56 ` David Riley
2000-12-15 1:05 ` Alexander Viro
2000-12-15 4:24 ` ferret
2000-12-16 11:30 ` Marcus Sundberg
2000-12-15 14:57 ` Kurt Roeckx
2000-12-15 15:23 ` Dana Lacoste
2000-12-15 22:28 ` Alex Buell
2000-12-16 22:41 ` Peter Samuelson
2000-12-18 15:51 ` Dana Lacoste
2000-12-18 17:08 ` Peter Samuelson
2000-12-18 19:32 ` David Schleef
2000-12-18 17:04 ` richard offer
2000-12-19 5:16 ` Peter Samuelson
2000-12-15 0:15 ` Alexander Viro
2000-12-15 7:21 ` LA Walsh [this message]
2000-12-15 11:05 ` Chmouel Boudjnah
2000-12-15 14:21 ` Werner Almesberger
2000-12-15 17:15 ` ferret
2000-12-15 17:46 ` Werner Almesberger
2000-12-15 20:29 ` Joe deBlaquiere
2000-12-15 21:27 ` Werner Almesberger
2000-12-15 22:58 ` Joe deBlaquiere
2000-12-15 23:56 ` Werner Almesberger
2000-12-16 22:50 ` Peter Samuelson
2000-12-17 0:04 ` Joe deBlaquiere
2000-12-17 2:05 ` Peter Samuelson
2000-12-15 18:10 ` LA Walsh
2000-12-15 21:02 ` Miquel van Smoorenburg
2000-12-16 4:04 ` ferret
2000-12-16 11:09 ` Miquel van Smoorenburg
2000-12-16 17:20 ` ferret
2000-12-17 0:21 ` J . A . Magallon
2000-12-16 23:10 ` Peter Samuelson
2000-12-17 1:15 ` Miquel van Smoorenburg
2000-12-17 2:18 ` Peter Samuelson
2000-12-15 21:21 ` Werner Almesberger
2000-12-15 21:36 ` LA Walsh
2000-12-15 22:48 ` J . A . Magallon
2000-12-15 23:47 ` Werner Almesberger
2000-12-16 4:11 ` ferret
2000-12-16 2:50 ` richard offer
2000-12-16 4:22 ` What about 'kernel package'? was: " ferret
2000-12-15 19:35 ` Matt D. Robinson
2000-12-15 21:36 ` Werner Almesberger
2000-12-18 17:48 Petr Vandrovec
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=NBBBJGOOMDFADJDGDCPHCENKCJAA.law@sgi.com \
--to=law@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@math.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox