Re: [patch/rfc] Generate makefile dependencies

[Ian Lance Taylor <ian@wasabisystems.com>]

Andrew Cagney <cagney@gnu.org> writes:

> > '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.

I would say that it depends on the speed cost.  Dependencies rarely
change.  In my opinion, it's not worth a measurable slowdown to
configure--a price paid by everybody who builds from source--to handle
them correctly.  If your code runs quickly, and correctly handles
things like the way mips-tdep.o depends upon
include/elf/reloc-macros.h (something which the current gdb Makefile
does not appear to get right), then I'm sure your plan is fine.

> 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.

The only people who need to update dependencies lists for the binutils
are people doing development on the binutils.  For those people, I do
not consider gcc to be a specialized tool.  (I do consider automake to
be a specialized tool.)  The set of people who do serious binutils
work and who do not have access to gcc on any platform is a null set.
And of course the dependencies are written so that they are very
simple to update by hand, for quick hacks by developers.

> 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.

The binutils use none of the above.  Maintainers are supposed to
update the dependencies when they change them.  We periodically update
the dependencies anyhow, to catch anything which wasn't handled
earlier.  And we update the dependencies at release time as well.

Ian