What happened to version.h?

[James Olin Oden]

On Wed, 18 Feb 2004, Jeremy Katz wrote:

> On Tue, 2004-02-17 at 21:01 -0500, James Olin Oden wrote:
> > On Mon, 16 Feb 2004, Jeremy Katz wrote:
> > 
> > > On Sat, 2004-02-14 at 14:12 -0500, Janina Sajka wrote:
> > > > I've just installed FC2 without a any particular problem--all looks OK.
> > > > But, I tried to compile a newer ALSA and it failed for lack of
> > > > /usr/src/linux/include/linux/version.h. Indeed, when I look in the
> > > > source tree--which is certainly there--version.h is not there. Is there
> > > > some new procedure re the 2.6 kernels that I'm unaware of?
> > > 
> > > ALSA should be look in /lib/modules/$(uname -r)/build not /usr/src/
> > > linux.   This is the Linux Approved Way.  And with the 2.6 kernels, the
> > > headers are being included in the individual packages instead of all in
> > > the kernel-source package which a) makes things a lot simpler and b)
> > > makes it so that you don't have to install krenel-source just to build a
> > > kernel module.
> > >
> > Ack!  It also makes it so your driver only builds against the currently 
> > running kernel.  Not a good thing if that is not your intent (and in my
> > universe, this is more likely the case than not).  I personally think 
> > its better to build against the sources of the kernel you wish your module
> > to run with.  Where I work, this is all automated, and I believe there
> > has been talk on the fedora-devel list concerning this (i.e. open source
> > versions of such tools).  Anyway, just my 2cents...james
> 
> So do /lib/modules/myrandomversion instead of /lib/modules/$(uname -r).
> Sane makefiles will even let you redirect it to /some/random/path.  But
> in the general case, keeping the actual headers (and the corresponding
> module version fun) with the kernel instead of having the mess of
> conditionals and nastiness (cf /boot/kernel.h and the hacks involved
> therein) is _far_ nicer.
>
Yeah but that still requires that that kernel had been installed at some 
time, where as with the source approach you can use rpm2cpio (or just 
untar the tarball if you like) to unpack the sources wherever you like,
and then do some preliminary configuration of the sources (i.e. setting up 
your config they way you like, or use the proper config from your distro 
vendor, and make deps, and stuff like that).  This approach can/has been 
automated, and generates a reproducible build of your device driver no 
matter what kernel is installed on your build server.

That being said, I make no claims to being an expert in this area (or any
other (-;), but from the perspective of generating a reproducible build,
requring to build against an installed kernel is not the right way to go;
you may think otherwise and have sane logical arguments against this, 
though.

Cheers...james
> Jeremy
> 
> 
>