This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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.
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.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |