Re: Header files not mentioned in the makefile

[Junio C Hamano <gitster@pobox.com>]

mkoegler@auto.tuwien.ac.at (Martin Koegler) writes:

> On Mon, Mar 03, 2008 at 11:47:01AM +0000, Johannes Schindelin wrote:
>> On Mon, 3 Mar 2008, Martin Koegler wrote:
>> 
>> > When I modified fetch-pack.h I was surprised by the fact, that it does 
>> > not result in rebuilding all object files. In fact, no file was rebuilt. 
>> > It turned out, that fetch-pack.h was not mentioned in the Makefile.
>> > 
>> > A quick search (on next) showed, that other header files are also not
>> > taking part in dependency checking:
>> > 
>> > $for a in `ls *.h`; do grep "$a" Makefile >/dev/null || (echo "missing: $a"; grep "$a" *.c|grep include) ; done
>> > missing: branch.h
>> 
>> Somehow I miss "wt-status.h" in your list.
>
> There is a dependency for wt-status.h, so it does not show up in
> my grep:
>  builtin-revert.o wt-status.o: wt-status.h
>
> But this is complete:
> $ grep wt-status.h *.c
> builtin-commit.c:#include "wt-status.h"
> builtin-revert.c:#include "wt-status.h"
> wt-status.c:#include "wt-status.h"

I've been meaning to do a Makefile clean-up.

 * Various lists (SCRIPT_SH, SCRIPT_PERL, PROGRAMS, LIB_H, ...).  Make
   them into a sorted one-item-per-line of the form "LIB_H += foo.h".

 * Dependencies.  We probably should auto-maintain them ("gcc -M",
   makedepend etc).

 * Removing libgit.a; it used to be that what we had was a collection of
   independent programs that link various but not all object files, and it
   was a very easy and low maintenance way to tell the linker "grab
   whatever you need from libgit.a".  These days, however, we roll almost
   everything into "git" as built-ins, and the private library outlived
   its usefulness.  We can instead just link in *.o files to build "git"
   directly.

I'd probably do the first item from the above list, immediately after all
the 1.5.5 topics graduat to 'master' and v1.5.5-rc1 is tagged; at that
point, by definition, we will not have new topics on 'master' until the
final.  This conversion should not be difficult nor disruptive from
technical point of view, but it needs to be done at the right moment when
everything is quiescent.