public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sam Ravnborg <sam@ravnborg.org>
To: Adrian Bunk <bunk@kernel.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 12:29:03 +0200	[thread overview]
Message-ID: <20070930102903.GA12747@uranus.ravnborg.org> (raw)
In-Reply-To: <20070930030258.GA10852@stusta.de>

On Sun, Sep 30, 2007 at 05:02:58AM +0200, Adrian Bunk wrote:
> On Sat, Sep 29, 2007 at 10:11:45PM +0200, Sam Ravnborg wrote:
> >...
> > The second is the more controversial suggestion.
> > In several Makefile we have simple if expression of the variants:
> > if ($(CONFIG_FOO),y)
> >   obj-$(CONFIG_BAR) += fubar.o
> > endif
> > 
> > The pattern varies over this theme.
> > The suggestion here is to introduce a few helpers:
> > 
> > obj-y-if-$(CONFIG_FOO) += fubar.o
> > This one shall read:
> > if $(CONFIG_FOO) is y or m then set += to obj-y
> 
> IMHO for people who are not kbuild junkies the pattern is more clear 
> with the current syntax.
> 
> But you should better ask some guinea pigs who have not already seen as 
> many kernel Makefiles as I have...

Target group are for kernel developers and people who have
actually read Documentation/kbuild/makefiles.txt

But point taken - this is too 'magic'.
I will try to think of something that looks a bit more straightforward.

> Some of the cases have the following pattern:
> 
> config X86_POWERNOW_K8_ACPI
>         bool
>         depends on X86_POWERNOW_K8 && ACPI_PROCESSOR
>         depends on !(X86_POWERNOW_K8 = y && ACPI_PROCESSOR = m)
>         default y
> 
> Your suggested syntax has to be enhanced with three additional
> variables for handling such cases.
> 
> 
> The complicated cases can be handled either in kconfig or in kbuild,
> and I think kconfig is the better place for them:

The kbuild enhancements are for the cases where it
makes less sense to express this in Kconfig.
They are not thought as replacing Kconfig dependencies in any way.

I will try to come up with a new proposal later today.

	Sam

  reply	other threads:[~2007-09-30 10:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-29 20:11 [RFC] Extending kbuild syntax Sam Ravnborg
2007-09-30  3:02 ` Adrian Bunk
2007-09-30 10:29   ` Sam Ravnborg [this message]
2007-09-30 13:36 ` Ingo Oeser
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=20070930102903.GA12747@uranus.ravnborg.org \
    --to=sam@ravnborg.org \
    --cc=bunk@kernel.org \
    --cc=kbuild-devel@lists.sourceforge.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