Re: Non-recursive makefiles

[Marc Alff]

Hi all,


Bob Friesenhahn wrote:
> On Mon, 29 May 2006, Stefan Puiu wrote:
>> However, people haven't mentioned yet the main point in Peter Miller's
>> paper - dependency handling, which I think is very important (I would
>> say significantly more important than the ability to type "make clean"
>> in one directory). Most people I work with are more familiar with
>
> There should be no need to type "make clean" in a subdirectory. Doing
> so is a rank admission that the build system is broken. Why else would
> someone want to do a "make clean" in a subdirectory? Perhaps the
> desire to do "make clean" in a subdirectory is aquired bad behavior?
>

I would like to add an observation to that discussion :

The build system depends on timestamps on the file system, and make can
be easily confused when the file system has unanticipated properties
due to configuration management.

Consider the following :

Day 1 : developer X writes some code (on his machine, not checked in yet)
Day 2 : I do a build on my machine
Day 3 : developer X checks-in the code, now that it has been tested ok.
Day 4 : I do a make again ... the source file given by the source
control system is dated Day 1, and my binary is older,
so it must be up to date, right ?

Another one :

I do a build pulling code from component X, Y and Z, using the code
labeled X1.13 for X.
Oops, that build has funny behavior, so I change the way I "see" the
code to use the older label X1.12 instead
(1 month old, but known to work for my need), so I can find out if my
change on component Y or team X change had an impact ...
Make ... sees a binary from today and source code 1 month old for X, so
the binary must be up to date, right ?

In both cases, make can only do so much based on "reasonable"
assumptions ("newer" files have a "more recent" time stamp),
but the source code itself varies in ways that make can not deal with
("newer = different" files sometimes go back in the past ... oops).

On top of that, sometimes, developers just want to have a build as
quickly as possible, to trouble shoot something.
For example, I have seen people editing header files with a "touchvi"
script, which had the interesting property of editing the content with vi,
and putting the original time stamp back ...
90 percents of the time, people doing that know what they are doing, and
use a selective (subdirectory) make clean / make
9 percent of the time, they just get lucky,
and of course, 1 percent of the time, the whole thing blows and needs a
huge clean/compile/link cycle again,
but the point is that on average it saves a lot of time during development.

So, there are cases where make clean; make in a subdirectory is useful,
especially when it saves time during the build.
The bigger the project is (and the longer it takes to build), the more
likely people will want to do a selective -- and granted, at your own
risk -- clean.

> That said, if one inspects the Automake generated Makefile, it does
> not take long to learn how to create specific clean targets which will
> work for a specific target.
>
> Bob

Marc Alff.