Why are header file touched in Makefiles ?
The reason I ask is that I am using a configuration management system to
maintain the linux kernel. It "checks out" all source files read-only
(actuall it uses symbolic links to a baseline directory which is
read-only). You then tell it which files you intend to modify and it
will check those files out as read-write to the local sandbox.
When trying to do a "make zImage" some of the header files (eg.
include/linux/types.h) are being touched by a dependency rule. The
build is failing as the files are readonly and can't be touched. I
don't understand why the header files need to be touched. Surely the
"make dep" should only generate rules to recompile .c files.
Thanks for any help explaining why header files need to be touched.
Regards,
Brendan Simon.
On Fri, 25 Jan 2002 16:54:39 +1100,
Brendan J Simon <[email protected]> wrote:
>Why are header file touched in Makefiles ?
To handle the two level dependencies on CONFIG options. bar.c depends
on foo.h which depends on CONFIG_BLIP. Change CONFIG_BLIP and the
Makefiles touch foo.h which in turn recompiles bar.c.
Yes, it sucks with source repositories. Which is why kbuild 2.5
completely removes this "feature", with kbuild 2.5 you can build from a
read only file system.
>You then tell it which files you intend to modify and it
>will check those files out as read-write to the local sandbox.
Even easier with kbuild 2.5, it has shadow trees. You keep the base
read only, copy the files to modify to a separate tree and kbuild 2.5
logically merges all the files.
http://sourceforge.net/projects/kbuild/
[Brendan Simon]
> Why are header file touched in Makefiles ?
Dependency reasons. Header files depend on whatever CONFIG options
they reference, and this is implemented via proxy header files. Say
you have foo.c which includes foo_bar.h which makes a reference to
CONFIG_BAR. The correct dep tree would be
foo.o: foo.c foo_bar.h CONFIG_BAR
but, as it turned out, it was easier / more efficient to represent the
tree as
foo.o: foo.c foo_bar.h
foo_bar.h: CONFIG_BAR
This second tree is not strictly correct -- foo_bar.h does *not* in
fact need to be rebuilt when CONFIG_BAR changes -- so the 'touch'
commands are there to make it work correctly.
If you don't like it (and most of us don't!), you should patch your
tree with Keith Owens's 2.5 makefile structure, "kbuild-2.5". It fixes
this problem (and many others). It is hoped that kbuild-2.5 will be
merged with Linux 2.5 in the near future.
Peter
Keith Owens wrote:
>Even easier with kbuild 2.5, it has shadow trees. You keep the base
>read only, copy the files to modify to a separate tree and kbuild 2.5
>logically merges all the files.
>
Does it allow to compile more kernels each with its own config from one
source tree?
Marian Jancar
On Mon, 28 Jan 2002 09:17:27 +0100,
Marian Jancar <[email protected]> wrote:
>Keith Owens wrote:
>
>>Even easier with kbuild 2.5, it has shadow trees. You keep the base
>>read only, copy the files to modify to a separate tree and kbuild 2.5
>>logically merges all the files.
>
>Does it allow to compile more kernels each with its own config from one
>source tree?
Yes, the .config is in the object directory. You can even compile for
different architectures from the same source tree at the same time.