Allowing a variable number of CONFIGs in commands gives a useful
reduction in the number of commands required by kbuild 2.5.
select(config objects) -> select(config objects) [ unchanged ]
always(objects) -> select(objects)
always_mod(objects) -> select(CONFIG_M objects)
objlink(objects) -> objlink(objects) [ unchanged ]
objlink_cond(config objects) -> objlink(config objects)
ifsel(config1) -> select(config2 config1 objects)
select(config2 objects)
endsel
Remove always, always_mod and objlink_cond, just use select and
objlink. No config means unconditional. CONFIG_M is set to 'm' if
CONFIG_MODULES is true, otherwise it is 'n'. CONFIG_Y also exists, it
is always 'y'.
When multiple configs occur in select, the first one determines how the
objects will be compiled. The other configs must all be selected as
'y' or 'm' to build the objects but they have no effect on how the
objects are built. This gives us the ability to do this :-
select(CONFIG_M config_list objects) - build the objects as modules
as long as the config_list is true, even if all the config_list is
built in.
Bits of debug code use this, like drivers/acpi/Makefile.in.
ifsel(CONFIG_KDB)
ifsel(CONFIG_ACPI)
always_mod(kdbm_acpi.o)
endif
endif
Replace with select(CONFIG_M CONFIG_KDB CONFIG_ACPI kdbm_acpi.o)
select(CONFIG_Y config_list objects) - build the objects into the
kernel as long as the config_list is true, even if any of the
config_list are set to 'm'.
The second construct occurs in a few places where some support code is
required in the kernel even if the main code is in a module. Order
matters.
Peter Samuelson was worried about the principle of least surprise.
IMHO the benefits of handling the unusual as well as the usual cases is
worth it, we just tell users that the most important config comes
first. Even if somebody makes a mistake and reverses the order, the
problem will show up immediately. An object that is built in when it
should have been a module or vice versa is easy to spot, in many cases
it will get unresolved references.
_______________________________________________
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
