Over the last few weeks I have pondered with the idea

to extend the current kbuild syntax.

The idea have existed for long but only recently I started

to think how to do this in a truely flexible manner.
Two areas are in need for a bit of attention to improve

current kbuild files in the kernel.
The first issue is the EXTRA_CFLAGS.

They are often conditionally assigned like in the following

example:
ifeq ($(DEBUG),y)

EXTRA_CFLAGS := -DDEBUG

endif
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/
The kbuild variable is named 'ccflags' to match the CC prefix

for the C compiler used in non-verose output.

And then it does not clash with current cflags-y usage too.
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
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 d...
[ message continues ]

obj-$(CONFIG_NFSD:m=y) += nfsctl.o
obj-$(CONFIG_PROC_FS:y=$(CONFIG_LOCKDEP)) += lockdep_proc.o
Andreas

-

Hi Sam,
Yes, but please bear in mind, what the developers are trying
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.
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

-

Perhaps this would work?
ifeq (${CONFIG_NO_MMU},)

obj-m += magic_mmu.o

-

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

Target group are for kernel developers and people who have

actually read Documentation/kbuild/makefiles.txt
But point taken - this is too 'magic'.
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

-