[systemd-devel] [PATCH] ease installation on non-running kernels

[Greg KH]

On Tue, Jun 17, 2014 at 03:53:15PM -0400, Dave Reisner wrote:
> On Tue, Jun 17, 2014 at 12:28:27PM -0700, Greg KH wrote:
> > On Tue, Jun 17, 2014 at 02:52:43PM -0400, Dave Reisner wrote:
> > > This lets KERNELDIR apply to the install target as well so that you can
> > > do something such as the following will Just Work™:
> > > 
> > >   make KERNELDIR=/lib/modules/3.15.0-foo install
> > > ---
> > >  Makefile | 14 +++++++-------
> > >  1 file changed, 7 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/Makefile b/Makefile
> > > index c593b51..fe4dd58 100644
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -17,7 +17,7 @@ kdbus$(EXT)-y := \
> > >  
> > >  obj-m += kdbus$(EXT).o
> > >  
> > > -KERNELDIR 		?= /lib/modules/$(shell uname -r)/build
> > > +KERNELDIR 		?= /lib/modules/$(shell uname -r)
> > >  PWD			:= $(shell pwd)
> > >  
> > >  all: module test
> > > @@ -26,7 +26,7 @@ test::
> > >  	$(MAKE) -C test KBUILD_MODNAME=kdbus$(EXT)
> > >  
> > >  module:
> > > -	$(MAKE) -C $(KERNELDIR) M=$(PWD)
> > > +	$(MAKE) -C $(KERNELDIR)/build M=$(PWD)
> > 
> > Nope, you just broke the build on my machine when I wanted to build
> > against the kernel source tree in /home/gregkh/linux/ that does not have
> > a build/ subdirectory in it.
> 
> Fair enough. I figured this would be the response I get [0].

Um, that should be the workflow of _any_ kernel developer, we all build
against local kernel directories, not one that is installed in /lib/.
Some of us don't ever boot kernels installed in /lib :)

> > What is wrong with putting the build/ trailing subdir in your build
> > command line?  What is currently broken today with the build system?
> 
> As the commit message implies, make install doesn't work for non-running
> kernels -- it will always install to the current kernel. So, after a
> kernel upgrade, I have to make the subdirectories myself, copy over the
> module, and run depmod before I can build an initramfs for the new
> kernel (and subsequently reboot).

Then fix up the install target, don't break the build target :)

> > And long-term, this will not be an issue at all as the code will be
> > merged into the kernel tree.
> 
> Sure, but unless I'm missing something, the status quo makes things a
> bit tedious for rebuilds. Most other out of tree modules I've come in
> contact with make this a trivial operation.

What do their makefiles look like that is different here?  The module:
target should be the same, right?

thanks,

greg k-h