On Sun, 26 Sep 2010, FX wrote: > How can we fix this? The only way I see would be to have two macros > instead of TARGET_OS_CPP_BUILTINS: one that will be used for > source-preprocessing in all languages (maybe keeping the name > TARGET_OS_CPP_BUILTINS), and one that will be used only for C-family > languages (TARGET_OS_CPP_BUILTINS_CFAMILY). It seems like a bit of work, > to get everything in the right place. However, I don't really see an > alternative solution, which is why I'm writing here: would there be any > easier solution? Or one that makes more sense to you?
If you're redesigning these macros, you ought to be designing things to use hooks instead anyway, though these macros probably aren't that easy to replace by hooks. You could I suppose define the hooks to take a structure of callbacks that they use in place of directly calling builtin_define or testing flag_isoc99 - or if you set up s separate hooks structure that is at least only used in front ends that link with libcpp, then you might reduce the number of callbacks needed. Or you could fully split things up as you suggest - put C-family-only hooks in targetcm, and libcpp-using hooks in a new structure. Splitting things up is probably cleaner than having a lot of callbacks. Whatever you do, you probably want to arrange for the code that is common between c-family/c-cppbuiltin.c and fortran/cpp.c (defining various language-independent macros) to be genuinely shared between front ends using libcpp, instead of duplicated. -- Joseph S. Myers jos...@codesourcery.com