On Sun, Dec 04, 2005 at 03:35:51PM +0100, Jonas Smedegaard wrote: > Thanks for the clarification. Indeed it works when passing the variables > to make environment instead of only to the outside one. > > The bigger aim is to allow building with standard Debian package > building tools rather than being forced to use make directly due to > specific arguments required passed.
Indeed, I'm all for having this all work in more manageable ways. But afaik, these packages should already _be_ compatible with all the usual ways of building kernel modules, from invoking make by hand, to make-kpkg and the debconf interface that will rebuild them automatically when you upgrade the source package. There are still some things ripe for common agreement and/or policy to form around though... > But you are right that then the > variables needing extra care should be explicitly declared. > > I believe the defacto-standard of module building comes from the > module building guideline written by Manoj as part of kernel-package, > but no real policy exist about this, I believe. The variables seeming > to require extra care is KSRC, KVERS, KDREV and KPKG_DEST_DIR. > > Read more here: http://wiki.debian.org/KernelModulesPackaging Ok. With the above in context, I'm even less sure that we want to make these sort of changes here. Any well behaved build helper is surely capable of passing these values in the preferred form without requiring pollution of the general environment with them, no? Where did the example command on the wiki page come from? Surely it should be edited to read more like the one I posted earlier, with the variable assignments passed as command args, if it is to be an example of what a build tool should do. > You use variables KSRC and KDREV identical to those mentioned above, and > seem to take extra care about KDREV being passed from the build > environment, but not KSRC. Why? Let's see... that code originally came from some boilerplate somewhere, probably dh-make initially (I've just filed a bug there about it still using kdist_config, but it looks different now), and there is a now non-existent: /usr/share/kernel-package/sample.module.rules cited there, certainly some stuff from Robert Milan was snaffled, then its been hand edited by me through a few generations since. However, from what I see in it today, if you are referring to: ifeq ($(strip $(KDREV)),) KDREV = "test1.0" endif ifeq ($(strip $(KSRC)),) $(error Error. I do not know how to determine the kernel version) else Then indeed, the logic is a little weird since the $(error) will never fire, as we explicitly set KSRC to a default just above. And the error itself is misleading. But I think the original motive had more to do with just ensuring they were always set to some value, rather than protecting values from the environment. In fact looking at this more, I think doing: KSRC ?= /usr/src/linux Really is wrong, whichever way we go. I guess we should probably replace the $(error) with an attempt to set KSRC to a reasonable default, and get rid of the else case altogether. Then we should have something that acts like you expected, but as a result of the whole lot being a bit more logical rather than through the addition of extra overrides. Or is there something else altogether that we should replace all these duplicated tests with? cheers, Ron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
