Re: [patch/rfc] Generate makefile dependencies

[Andrew Cagney <cagney@gnu.org>]

> Andrew Cagney <cagney@gnu.org> writes:
> 
> 
>>>> > BTW, your comment about running automake to update deps in BFD is
>>>> > actually incorrect.  You run 'make dep-am', which IIRC seds Makefile.am
>>>> > and maye regenerates Makefile.in; the dependencies aren't managed by
>>>> > automake.  Recent versions of automake do have top-notch dependency
>>>> > support though.
>>
>>> 
>>> It appears to eventually run "gcc -MM" ... :-(
> 
> 
> Assuming you are talking about 'make dep-am' in the binutils, that is
> irrelevant.

> 'make dep-am' is run by a binutils maintainer, not by an ordinary
> user.  It does happen to run gcc -MM, so the binutils maintainer is
> required to have gcc installed.  However, the result is the correct
> dependencies for any compiler, and those dependencies are then present
> in the Makefile for any user, regardless of what compiler they use.

Right, which was part of my motivation for proposing that it be done 
this way:

> The attached, er, hack, modifies configure.in so that all the Makefile dependencies are generated during configure time:
> 
>     defs_h = ...
>     foo.o: foo.c $(defs_h)
> 
> It exploits the fact that GDB's code base is very consistent in its use of "foo.h" vs <foo.h> -- the former is assumed to be local, the latter in a system library.
> 
> Instead of having to to edit Makefile.in, or as with binutils, run automake, you just enter:
>     ./config.cache --recheck
> 
> Thoughts?  Wonder how portable my SED is. 

While Daniel's pointed out that for binutils "make dep-am" (and hence 
gcc -MM) and not "automake" are used, the problem still stands - correct 
dependency lists are only available if a specialized set of tools are 
installed.

For what its worth, I know of three ways to maintain a dependency list:

- update at compile time

- update at configure time

- update at release time

For someone grabbing random sources, the first is most likely correct, 
the last is most likley out-of-date.  The middle is a compromise, at 
least correct at the start of each build.

Andrew