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