public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Adrian Bunk <bunk@kernel.org>
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 05:02:58 +0200	[thread overview]
Message-ID: <20070930030258.GA10852@stusta.de> (raw)
In-Reply-To: <20070929201145.GA20377@uranus.ravnborg.org>

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...

> In several cases we will need it to be more complicated like the this:
> obj-y-ify-$(CONFIG_FOO) += fubar.o
> This one shall read:
> if $(CONFIG_FOO) is y (thats the ify thing) then += to obj-y
> 
> And we can mix it like the following:
> obj-$(CONFIG_BAR)-ify-$(CONFIG_FOO) += fubar.o
> This one shall read:
> if $(CONFIG_FOO) equal y then += to obj-$(CONFIG_BAR)
> 
> 
> The full list of new variables are (for obj-y):
> obj-y-if-y
> obj-y-if-m
>
> obj-y-ify-y
> obj-y-ifm-m
> 
> obj-y-ifn-
> 
> And similar for obj-m:
> obj-m-if-y
> obj-m-if-m
> 
> obj-m-ify-y
> obj-m-ifm-m
> 
> obj-m-ifn-
> 
> The 'y' and 'm' can be replaced by $(CONFIG_FOO) but the one right
> to the if are not supposed to be replaced.
> 
> 
> To better express how to use it I have tried to update a few Makefiles
> to use the new syntax. See below.
> 
> On MAJOR drawback is the linking order.
> I have no way to keep the link order if the new syntax are sued. The
> .o files will either be put before .o files specified with obj-y or obj-m or
> after the same.
> 
> For some places this does not matter but for other places (fs/Makefile)
> I will expect it to matter a lot.
> 
> Comments?
> Is this just to magic for bare humans to grasp.
> Or mabe the linking order is so important that we do not want it?
>...

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:

Handling it in kconfig has the advantage that we also get a variable we 
can use in C code.

For all the *-if-m and *-m-if{,n}-* cases this is a huge advantage over 
having to express the whole dependency in each #if.

Compare
  #if defined(CONFIG_ACPI_PROCESSOR) || (defined(CONFIG_ACPI_PROCESSOR_MODULE && defined(MODULE))
with
  #ifdef CONFIG_X86_POWERNOW_K8_ACPI

> 	Sam
>...

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


  reply	other threads:[~2007-09-30  3:02 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 [this message]
2007-09-30 10:29   ` Sam Ravnborg
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=20070930030258.GA10852@stusta.de \
    --to=bunk@kernel.org \
    --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