dkms shouldn't source all the variables in dkms.conf

[Peter Petrakis]

If you've got something like this in your package's dkms.conf

MAKE="make -C .... M=$(pwd) modules"

M becomes the current working directory from where you called dkms, and not the
working directory of the source code which is what you would expect.

If dkms has actually parsed the config file this could have been avoided, and the needless
makefile that must accompany this quirk just to satisfy dkms.

The workaround is:

MAKE="make KVER=$kernelver"
..
Makefile

all:
        make -C /lib/modules/$(KVER)/build M=$(shell pwd) modules

clean:
        make -C /lib/modules/$(KVER)/build M=$(shell pwd) clean

MAKE and CLEAN or anything intended to be executed in the context of the build
shouldn't be executed until they're necessary.

[Jerone Young (jerone)]

How is this a bug? Why whould you use $(pwd)?? Wouldn't specifing "." be better?

DKMS has been doing this for a long time now. Actually changing this logic could break dkms packages dependent on it.

I am confused by your statement " If dkms has actually parsed the config file this could have been avoided, and the needless
makefile that must accompany this quirk just to satisfy dkms."? It does parse the config

DKMS will only run MAKE & CLEAN during build. It also does not run clean arbitrarily only when cleaning up.

[Jerone Young (jerone)]

Your Makefile should not be this way. It should look like this:

KERNELDIR := /lib/modules/`uname -r`/build

obj-m := <module_name>.o

all:
        $(MAKE) -C $(KERNELDIR) M=`pwd` modules
clean:
        $(MAKE) -C $(KERNELDIR) M=`pwd` clean

[Jerone Young (jerone)]

In comment #5 I meant .. Why whould you use $(pwd) and not `pwd`?

[Peter Petrakis (peter-petrakis)]

@Jerone,

Kbuild is driving the object rules, the obj-m line is redundant and done
wrong could even break the build. The KERNELDIR var is completely
unnecessary. Your approach also precludes the developer from building
against other kernel versions that are on the system but not currently running.

On 06/30/2010 04:17 AM, Jerone Young wrote:
> Your Makefile should not be this way. It should look like this:
>
> KERNELDIR := /lib/modules/`uname -r`/build
>
> obj-m :=<module_name>.o
>
> all:
> $(MAKE) -C $(KERNELDIR) M=`pwd` modules
> clean:
> $(MAKE) -C $(KERNELDIR) M=`pwd` clean
>

[Jerone Young (jerone)]

@Peter
         You do need it .. or you rename it variable $KERVER .. but why are you using $(pwd) & not `pwd` ?his

         Your bug is not valid since you should be using `pwd`.

[eraserix (eraserix)]

Peter,

Why do you need to specify a makefile at all? I find it much more convenient to just have the Kbuild-File around at the same level as dkms.conf (e.g. toplevel in your modules directory) and let dkms worry about the rest. If you don't specify a MAKE-entry, dkms will use the following command to compile your module:
make -C $kernel_source_dir M= $dkms_tree/$module/$module_version/build

[Mario Limonciello (superm1)]

 Peter:

This should behave a lot better with git head. The file should be more safely parsed. Take a look at the new safe_source function.

On 06/29/2010 05:08 PM, Peter Petrakis wrote:
> Public bug reported:
>
> If you've got something like this in your package's dkms.conf
>
> MAKE="make -C .... M=$(pwd) modules"
>
> M becomes the current working directory from where you called dkms, and not the
> working directory of the source code which is what you would expect.
>
> If dkms has actually parsed the config file this could have been avoided, and the needless
> makefile that must accompany this quirk just to satisfy dkms.
>
> The workaround is:
>
> MAKE="make KVER=$kernelver"
> ..
> Makefile
>
>
> all:
> make -C /lib/modules/$(KVER)/build M=$(shell pwd) modules
>
> clean:
> make -C /lib/modules/$(KVER)/build M=$(shell pwd) clean
>
>
> MAKE and CLEAN or anything intended to be executed in the context of the build
> shouldn't be executed until they're necessary.
>
> ** Affects: dkms
> Importance: Undecided
> Status: New
>

[Peter Petrakis (peter-petrakis)]

eraserix,

These aren't always packaged from scratch so I don't get to choose how the
source code is setup. It's also not the Kbuild file that's the issue, it's
the makefile that's driving the build in the directory above. This makefile
has no concept of dkms' existence nor should it. While the rune you
specified below looks promising, I've been burned many times by dkms and it's
quirks and would prefer it did what I told it to do explicitly rather than
rely on some internal default which might break in some subtle way in a
future version. I might give this rune a try as an explicit dkms MAKE define,
thanks.

On 08/05/2010 11:20 AM, eraserix wrote:
> Peter,
>
> Why do you need to specify a makefile at all? I find it much more convenient to just have the Kbuild-File around at the same level as dkms.conf (e.g. toplevel in your modules directory) and let dkms worry about the rest. If you don't specify a MAKE-entry, dkms will use the following command to compile your module:
> make -C $kernel_source_dir M= $dkms_tree/$module/$module_version/build
>

[Mario Limonciello (superm1)]

Essentially this should be fixed by this commit:
http://linux.dell.com/cgi-bin/gitweb/gitweb.cgi?p=dkms.git;a=blobdiff;f=dkms;h=ee6a3f093cb69c1f065eb6679201f71b7a0c6cb7;hp=39e80b413a4f61fcc03f146b15765e90150d79fb;hb=edb4f84a10f8f2a35d75f6e7b8ddf8fe4194fbe8;hpb=2c06573e4193c764afcc11e850dd6b8361fc2de1

There are some later applicable commits after that too however.