public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sam Ravnborg <sam@ravnborg.org>
To: FN <zzzz444@ml1.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: module builds need improvement / top Makefile not good enough
Date: Fri, 2 Mar 2007 19:50:35 +0100	[thread overview]
Message-ID: <20070302185035.GA19305@uranus.ravnborg.org> (raw)
In-Reply-To: <1172855662.23830.1177403935@webmail.messagingengine.com>

On Fri, Mar 02, 2007 at 09:14:22AM -0800, FN wrote:
> Hello list,
> 
> I am unhappy with the direction the 2.6 kernel builds have taken.
> Very much like Micro$loth DDKs we (linux users) are being forced to
> build
> modules by plugging into a framework that doesn't respect the fine
> aspects
> of dependency generation and analysis.

The build system for the kernel (kbuild) have a number of goals to fulfill.
The most important ones was to be reliable and easy to use.
The easy to use part has mandated a very simple syntax in the
more than 1000 Makefiles in the kernel - and kbuild has been extended
support external modules too.

With the 2.6 kernel it is mandatory to use kbuild for external
modules for a number of reasons:
-> compiler and to some extent linker options now much more rely on
   the actual configuration. So a gcc commandline for a module may look
   different depending on the actual configuration.

-> The module support code is well integrated with kbuildand when
   it changes (and it does so now and then) then all external modules
   do not need to apply the same changes.

-> Same syntax for in-kernel and external modules makes it simpler.


The infrastructure used to achieve the goals of simplicity and reliability
rely and a great deal of the features supported by GNU make and that
clearmake and others does not support.
So faced with the two possibilities which is 
1) to rely on less GNU make features and support other make tools
2) full feature set but rely on GNU make
the choice was easy.

The point here is that even if kbuild was changed slightly to allow a user
to specify an alternative make program when building external modules
that would not work because kbuild rely too much on the GNU make features.

You can try this today.
MAKE=/usr/bin/my_make_utility make M=`pwd`

And see how it fails due to use of GNU make features.

	Sam

  parent reply	other threads:[~2007-03-02 18:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-02 17:14 module builds need improvement / top Makefile not good enough FN
2007-03-02 17:26 ` Jeremy Fitzhardinge
2007-03-02 18:50 ` Sam Ravnborg [this message]
2007-03-04 21:47 ` Oleg Verych
2007-03-05 13:53   ` FN
2007-03-05 16:07     ` Jan Engelhardt
2007-03-05 16:47     ` Randy Dunlap
2007-03-05 17:03     ` Stuart MacDonald
2007-03-05 19:08     ` Sam Ravnborg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070302185035.GA19305@uranus.ravnborg.org \
    --to=sam@ravnborg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zzzz444@ml1.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox