From: Ingo Oeser <ioe-lkml@rameria.de>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: kbuild devel <kbuild-devel@lists.sourceforge.net>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] Extending kbuild syntax
Date: Sun, 30 Sep 2007 15:36:55 +0200 [thread overview]
Message-ID: <200709301536.57156.ioe-lkml@rameria.de> (raw)
In-Reply-To: <20070929201145.GA20377@uranus.ravnborg.org>
Hi Sam,
On Saturday 29 September 2007, Sam Ravnborg wrote:
> Introducing the following new variable could make this a oneliner:
> ccflags-y
>
> ccflags-$(DEBUG) := -DDEBUG
>
> grep -r -C 1 -B 1 EXTRA_CFLAGS shows that the above is a
> very common pattern especially in drivers/
ACK. Also ACK for asflags, if done the same way :-)
> The second is the more controversial suggestion.
Yes, but please bear in mind, what the developers are trying
to express in these cases.
> In several Makefile we have simple if expression of the variants:
> if ($(CONFIG_FOO),y)
> obj-$(CONFIG_BAR) += fubar.o
> endif
This is "feature FOO of module BAR" where the feature itself
cannot be a module. The composition scheme described in
section 3.3 is at least equally useful. And that is used today.
Maybe the documentation of that scheme is not prominent enough :-)
> obj-y-ifn-
This is the only one needed, because it is cumbersome to express
negative rules in kbuild to include stubs (e.g. nommu stuff).
But again this can be done with composition rules right now, but
is order dependent. If we could get rid of this requirement,
I would be happy already. So kbuild is just lacking an "else"
clause here.
Best Regards
Ingo Oeser
next prev parent reply other threads:[~2007-09-30 13:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-29 20:11 Sam Ravnborg
2007-09-30 3:02 ` Adrian Bunk
2007-09-30 10:29 ` Sam Ravnborg
2007-09-30 13:36 ` Ingo Oeser [this message]
2007-10-01 20:35 ` Jan Engelhardt
2007-10-01 22:57 ` Andreas Gruenbacher
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=200709301536.57156.ioe-lkml@rameria.de \
--to=ioe-lkml@rameria.de \
--cc=kbuild-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=sam@ravnborg.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
all inboxes | Powered by JetHome®