On Mon, 2003-03-03 at 16:09, David Dawes wrote: > Is it safe these days to unconditionally use /lib/modules/`uname -r`/build > for $LINUX_SRC_DIR?
It's probably as good a _default_ as any. We shouldn't make it too hard to change though. > Will a single Makefile.kernel work for all versions of the kernel, > and handle various incompatibilities that arise from time to time > that the current Makefile.linux is forced to work around? It can be made to work without much difficulty, yes. For hints see http://www.infradead.org/cgi-bin/cvsweb.cgi/mtd/drivers/mtd/GNUmakefile?rev=1 http://www.infradead.org/cgi-bin/cvsweb.cgi/mtd/drivers/mtd/Makefile?rev=1 http://www.infradead.org/cgi-bin/cvsweb.cgi/mtd/drivers/mtd/Rules.make?rev=1 You don't actually need to muck with Rules.make if you don't want to support 2.2 kernels, IIRC. > If so, then that's definitely the way to go. I'd love to see > something cleaner than what we currently have (the Makefile for > the FreeBSD drm modules is very clean). Well if you only really care about i386 PeeCee builds and 2.4 or 2.2 kernels you can happily hard-code your CFLAGS and root around to find suitable headers, but if you want it to be portable and future-proof you really ought to be using 'make SUBDIRS=...'. There are problems with that approach too -- some distributions' kernel-source packages are broken as shipped, and you need to make mrproper, copy the relevant config from the 'configs' directory and 'make oldconfig dep' before you can build external modules. But that breakage needs to be fixed anyway, so I wonder whether we need to bother to work around such brokenness? -- dwmw2 _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
