Re: build system rules & algorithms

[Mike Shal]

On 6/18/09, Sam Ravnborg <address@hidden> wrote:
> In the linux kernel the following will trigger a rebuild:
>  - prerequisites missing/out-dated
>  - command change
>  - change in command line options (changing order does not trigger a rebuild)
>  - change of a CONFIG_* option used by a file or one of the prerequisites
>
>  We do all this with a small helper program and some non-trivial gmake
>  file syntax. But it is doable.

The kernel Makefile system really is quite nice - I especially like
the separation of the "build logic" (like the individual component
Makefiles) from the rest of the make syntax. I wasn't aware you could
change the order of arguments without triggering a rebuild. Aren't
things like the order objects are given to the linker important in the
kernel? Perhaps I misunderstand what you mean by your third bullet
there.

>
>  I consider it a bug if anyone can prove that a make clean; make solves
>  an issue when dealing with the kernel.
>  We have had issues but in general people rely on this in their
>  everyday use.

I think an important the distinction here is if anyone can offer a
similar proof, I would consider it a bug in *tup*, not the user's
Tupfiles. Though for the kernel you might say the build system is
really kbuild, which adds that feature to make. Unfortunately the same
guarantee does not apply to all users of make. Maybe it just comes
down to where you draw the line in the sand as to what the "build
system" is responsible to do.

Somewhat related, I also consider it a bug in tup if a user is able to
write a set of Tupfiles that aren't parallel safe (as in, it would
work with -j1 but might execute things in the wrong order with -j2).

-Mike