lkml.org 
[lkml]   [2004]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/2] kbuild updates
    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
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:04    [W:0.025 / U:120.408 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site