On Thu, 31 Jul 2014, Richard Biener wrote: > Actually after looking again I was wrong. main.c and toplev.c > are the "driver". So if we can make all frontends shared objects > with their only interface being their lang_hooks that would be nice > (of course the middle-end still needs to make gazillions of symbols > available to that "plugin").
As far as I know, the main non-lang-hook interface provided by front ends is the "convert" function (and there aren't that many places outside the front ends that still use it). So it shouldn't be hard to get to the state where each front end is only used by its langhooks. (That's a long way from any sort of independent buildability, though; everything still embeds global information about such things as command-line options for all available front ends, and tree codes likewise.) I don't personally like the relics of other such magic-named functions in the form of langhooks-def.h defaulting to a langhook having a particular name that a front end can provide #define LANG_HOOKS_GLOBAL_BINDINGS_P global_bindings_p #define LANG_HOOKS_PUSHDECL pushdecl #define LANG_HOOKS_GETDECLS getdecls and think it would be better for each front end to have unique names for these, with no such default. I think there are a few more cases where C and C++ provide different implementations of a function with the same name for use by c-family code (and ObjC / ObjC++ issues as well, of course). -- Joseph S. Myers jos...@codesourcery.com
