From: "FN" <zzzz444@ml1.net>
To: linux-kernel@vger.kernel.org
Subject: module builds need improvement / top Makefile not good enough
Date: Fri, 02 Mar 2007 09:14:22 -0800 [thread overview]
Message-ID: <1172855662.23830.1177403935@webmail.messagingengine.com> (raw)
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.
Two problems I've identified
1. module builds are forcing me to use a particular make program (gnu
make)
Well, what if someone uses a different tool to express the DAG (dep.
graph)?
2. gnu make is a somewhat dated program and can't do profound dependency
generation and analysis like some newer tools. All it can do is
produce
.d from .c with the -MM option using an idiom like this
-include f1.d f2.d
%.d: %.c
$(CC) -MM <whatever>
But that's not good enough for 2 reasons.
a) version rollback that causes timestamp rollback in time does NOT
trigger regeneration of dependencies (e.g. clearcase based
builds).
b) dependencies on order of things can't be expressed in gnu make,
for
example -Iinc1 -Iinc2 causes different results from -Iinc2 -Iinc1
if you have 2 different header files that have the same name in
both
directories. Same goes for "ld -r -o mod.o f1.o f2.o" vs
"ld -r -o mod.o f2.o f1.o" if order mattered (which it doesn't in
this case).
Bottom line - there exist free tools that are vastly superior to gnu
make,
one such example is omake, and I don't want you to force me to switch
to
inferior dependency analysis with gnu make.
My suggestion how to solve this problem is the following.
Instead of
gnumake -C /lib/modules/`uname -r`/build M=`pwd` modules
it's better to be able to do
gnumake -C /lib/modules/`uname -r`/build M=`pwd` MYMAKE=mymake modules
and then inside your gnu Makefile you'd call mymake like so
chdir $(M)
mymake MODFLAGS="whatever modflags" INCFLAGS="whatever incflags" modules
and pass on whatever flags are necessary.
You can set MYMAKE to gmake if unspecified thus "MYMAKE ?= make"
That would make the callback into the user's build environment clean and
unbind it from gnu make.
Any replies, critique -- cc me, as I am not on this list.
--
FN
zzzz444@ml1.net
--
http://www.fastmail.fm - And now for something completely different
next reply other threads:[~2007-03-02 17:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-02 17:14 FN [this message]
2007-03-02 17:26 ` module builds need improvement / top Makefile not good enough Jeremy Fitzhardinge
2007-03-02 18:50 ` Sam Ravnborg
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=1172855662.23830.1177403935@webmail.messagingengine.com \
--to=zzzz444@ml1.net \
--cc=linux-kernel@vger.kernel.org \
/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