Absolutely agree, which is why there are so many FIXME comments in the
Makefile.in files, to remove all the relative includes. If a source
needs a non-standard include ioutside the current directory then it
should #include <foo.h> and the makefile should point to the directory
containing foo.h. Knowledge about non-standard include files should be
in the makefile, not embedded in lots of source code.
That still leaves the question of where the generated files should be
written to. This is getting into philosophy rather than technical, one
man's preference is another's pet hate. My preference is not to write
to any directory under include. At the moment kbuild 2.5 has a clean
separation between shipped files under /include and generated files
under arch/$(ARCH). There are only 5 generated include files and they
are only present for historical reasons.
include/linux/modversions.h
include/linux/version.h
include/linux/uts_release.h
include/linux/autoconf.h
include/linux/compile.h
Writing to include/asm is a problem for kbuild 2.5. When using
separate source and object trees, the asm-$(ARCH) symlink cannot be
created in the source tree, users may want to generate multiple
architectures from a single source tree. .tmp_include/src_000/asm is
created in the object tree, pointing at the relevant source directory
and gcc scans .tmp_include/src_000, not the source tree.
If you write to asm/foo.h then you are updating the source tree. I can
work around this by creating two sets of symlinks for include paths,
one pointing to the object directory, one to the source and telling gcc
to scan the object first. But that will make the generated commands
even longer and will slow gcc down.
My preference is to generate files in the arch subtree. The source
code does #include <foo.h> and the makefiles have lines like this
extra_aflags(entry.o -I arch/$(ARCH))
Yes, you have to add extra_aflags on every object that uses the
generated include file. But you already have to specify a dependency
from the object to the generated file to ensure that parallel make
waits until the file is generated. Doing two lines instead of one for
the affected objects is no big deal.
$(objfile entry.o): $(objfile /arch/$(ARCH)/offsets.h)
extra_aflags(entry.o -I arch/$(ARCH))
BTW, mach-types.h is going to be a problem wherever it is stored.
Several .h files include the generated file so all objects that include
these .h files are dependent on mach-types.h being generated first.
include/asm-arm/arch-ebsa285/time.h:#include <asm/mach-types.h>
include/asm-arm/arch-ebsa285/uncompress.h:#include <asm/mach-types.h>
include/asm-arm/arch-ebsa285/irq.h:#include <asm/mach-types.h>
include/asm-arm/arch-ebsa285/system.h:#include <asm/mach-types.h>
include/asm-arm/arch-ebsa285/irqs.h:#include <asm/mach-types.h>
include/asm-arm/arch-arc/ide.h:#include <asm/mach-types.h>
include/asm-arm/arch-sa1100/uncompress.h:#include <asm/mach-types.h>
include/asm-arm/arch-sa1100/ide.h:#include <asm/mach-types.h>
include/asm-arm/arch-sa1100/irq.h:#include <asm/mach-types.h>
include/asm-arm/arch-sa1100/hardware.h:#include <asm/mach-types.h>
I do not want to reinvent make dep because of the fundamental design
problems with that approach. If any generated file depends on .config
then it must be recreated after any config changes or patches but 99.9%
of users do not do that. We must not rely on human intervention to
update kernel files, it must be automatic. This requires that make be
told the truth about the dependency graph. mach-types.h is going to
require some more work, no matter where it is stored.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/