> i'd like to add it here that Makefile polishing is important - it's just
> that in the context of arch/*x86* the Makefile impact of the current
> cross-arch code sharing practice is one of the smaller problems and the
> Makefiles get cleaned up via the arch/x86 merge anyway.
Partly so. Took a look at the x86 tree.
The main Makefile are at least not merged. Neither are pci/Makefile not
And some of the rest of the Makefiles are not pretty with the huge arch
specific sections ifdeffed out.
I have long thought about some extensions to the kbuild 'language'
along the following lines:
Additional shorthands for obj-m:
Additional shorthands for obj-y:
The ifn- versions are to test for empty options.
This may as an example result in following changes to the
acpi/Makefile in the merged tree:
Makefile | 14 +++++---------
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kernel/acpi/Makefile b/arch/x86/kernel/acpi/Makefile
index ad4baa6..ec5a295 100644
@@ -1,15 +1,11 @@
obj-$(CONFIG_ACPI) += boot.o
-obj-$(CONFIG_X86_IO_APIC) += earlyquirk.o
-obj-$(CONFIG_ACPI_SLEEP) += sleep_32.o wakeup_32.o
-obj-$(CONFIG_ACPI_SLEEP) += sleep_64.o wakeup_64.o
+obj-$(CONFIG_X86_32)-if-$(CONFIG_X86_IO_APIC) += sleep_32.o wakeup_32.o
-obj-y += cstate.o processor.o
+obj-$(CONFIG_X86_32)-if-$(CONFIG_ACPI_SLEEP) += sleep_32.o wakeup_32.o
+obj-$(CONFIG_X86_64)-if-$(CONFIG_ACPI_SLEEP) += sleep_64.o wakeup_64.o
+obj-y-if-$(CONFIG_ACPI_PROCESSOR) += cstate.o processor.o
My biggest worry is that we end up with a more compact format
but only me (and a very few others) can read it.
But I think the above could make the x86 Makefiles more readable
as a whole.
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
kbuild-devel mailing list