touch commands in Makefiles

touch commands in Makefiles

[Brendan J Simon]

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.

Re: touch commands in Makefiles

[Keith Owens]

On Fri, 25 Jan 2002 16:54:39 +1100, 
Brendan J Simon <brendan.simon@bigpond.com> 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/

Re: touch commands in Makefiles

[Peter Samuelson]

[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

Re: touch commands in Makefiles

[Marian Jancar]

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

Re: touch commands in Makefiles

[Keith Owens]

On Mon, 28 Jan 2002 09:17:27 +0100, 
Marian Jancar <jancar@nmskb.cz> 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.