Re: [PATCH 0/2] kbuild updates

[Jari Ruusu <jariruusu@users.sourceforge.net>]

Sam Ravnborg wrote:
> On Mon, Jun 21, 2004 at 12:03:19AM +0200, Sam Ravnborg wrote:
> > If I get just one good example I will go for the object directory, but
> > what I have seen so far is whining - no examples.
> 
> Now I recall why I did not like the object directory.
> I will break all modules using the kbuild infrastructure!

No it does not. If 'export KBUILD_OUTPUT=/foo' command is used used before
kernel is built, it is not any more difficult to compile external modules
with that same env variable defined.

> Why, because there is no way the to find the output directory except
> specifying both directories.
> One could do:
> make -C /lib/modules/`uname -r`/source O=/lib/modules/`uname -r`/build M=`pwd`
> 
> So the currect choice is:
> 1) Break modules that actually dive into the src, grepping, including or whatever
> 2) Break all modules using kbuild infrastructure, including the above ones

or 3) Add the missing object symlink. It does not break anything.

If and when external module build scripts are updated to automatically
detect the /lib/modules/`uname -r`/object symlink, users can even unset the
KBUILD_OUTPUT= env variable and external modules will still compile ok.

> I go for 1), introducing minimal breakage.

You seem to be in some strange "I must destroy... I must destroy... I must
destroy..." mental state. There is a no-breakage alternative and you just
will not consider that at all.

> If kernels are shipped with separate source and output then we better break
> as few modules as possible. And the introduced change actually minimize breakage.

Nope. Solution #3 is the minimal breakage solution.

> So the patch will not change.

In which case Andrew and Linus should consider revoking your kbuild
maintainer status. I moved Andrew and Linus from CC list to TO list in hope
to get this small question answered:

Andrew, Linus,
How about choosing someone else less destructive to maintain kbuild?

> See the following table:
> 
>                                           Current kbuild                With patch
> simple module, no grepping
> kernel source + output mixed                  OK                           OK
> 
> simple module, no grepping
> kernel source separate from output            FAIL *1                      OK
> 
> module grepping in src
> kernel source + output mixed                  OK                           OK
> 
> module grepping in src
> kernel source separate from output            FAIL *2                      FAIL *3
> 
> FAIL *1 Module cannot build because it fails to locate the compiled files used for kbuild.
>         Also the kernel configuration is missing.

Same 'export KBUILD_OUTPUT=/foo' will work the same for kernel build and
external module build. Your "FAIL *1" is bogus.

> FAIL *2 Same as FAIL *1. Module cannot build because kbuild compiled files are missing and
>         it cannot access kernel configuration.
>         Also it fails to locate files when grepping.

Same 'export KBUILD_OUTPUT=/foo' will work the same for kernel build and
external module build. Your "FAIL *2" is also bogus.

> FAIL *3 Grep will fail because it try to grep in files located under build/

Yep.

-- 
Jari Ruusu  1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9  DB 1D EB E3 24 0E A9 DD