On 6/18/09, Sam Ravnborg <s...@ravnborg.org> 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 _______________________________________________ Help-make mailing list Help-make@gnu.org http://lists.gnu.org/mailman/listinfo/help-make
