Patch: automatic dependencies for gcc

Tom Tromey tromey@redhat.com
Sun Mar 9 16:02:00 GMT 2008


>>>>> "Ralf" == Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:

>> This makes it tempting to change depcomp instead  :)

Ralf> Fair enough.  Well, the one-time complexity of the above should be
Ralf> weighed against losing sync with upstream (hmm, not too dynamic ATM ;-).

If I were to change depcomp, and I probably am not really going to, I
suppose I would parameterize the location of the dep file and push the
change upstream.  I certainly don't think gcc should maintain
long-term forks of externally-maintained support programs like this.

Ralf> The reason I see against my proposal that IMVHO carries real weight
Ralf> would be if you were to require up to date deps files.  I would not know
Ralf> how to easily reformulate
Ralf>   %.o $(DEPDIR)/%.d: %.c
Ralf> rules into the subdir/$(DEPDIR) scheme.  Why aren't you using this BTW?
Ralf> It would already be a bit safer than what you currently have, even if
Ralf> you don't go all the way and make $(DEPFILES) a prerequisite of 'all'.

It seems to me that this will cause us to run these rules at -include
time.  -include will not error if the file does not exist, but if the
file can be remade, make will try to do that.

I think include time is too early to build the .d files.

Tom



More information about the Gcc-patches mailing list