Cleanup C frontend function deferring

[Zack Weinberg]

Geoff Keating <geoffk@geoffk.org> writes:

>> necessary so that cpplib can be built for the build machine as well as
>> the host (rather like libiberty is now).  The thing currently blocking
>> that is the use of GTY in hashtable.c; a standalone cpplib obviously
>> cannot use the garbage collector at all.
>
> You mean stringpool.c?  hashtable.c doesn't use the garbage collector
> at all.

Yes.  I got mixed up.

> stringpool.c is pretty much GCC-specific.  It's all IDENTIFIER_NODE
> and ggc_*.

Hmm.  You may have a point.  cpplib can be used without stringpool.c,
else fix-header wouldn't work.  I remember trying it and getting
stuck, though.

> I'd prefer that we just use
>
>         gcc -MMD ...
>
> and GNU make, and combine the resulting dependency files (because
> otherwise you get way too many stat() calls from GNU make).

Won't work.  Really.  Consider tm.h, which is a generated header that
consists entirely of includes of other headers.  -MG assumes that
generated headers are leaves of the include graph, so it will
miscalculate dependencies in this case.  And tm.h includes generated
headers (it shouldn't, but that's a separate problem).  The net effect
would be that insn-constants.h/insn-flags.h would never get built.

Yeah, you can put special case code all over the Makefile, but why not
just write a custom dependency-generation utility which will allow us
to get it right?

> Forgetting the #include is not a problem, because it will cause a
> link-time error and so people notice.  The bigger problem is when
> people forget to mention a file to gengtype at all, because that
> causes a silent failure.

Good point.  Okay, I won't worry about that bit.

zw