Re: [patch] Separate {OS,CPU}_CPP_BUILTINS macros into C-family and language-independent macros

[Jerry DeLisle <jvdelisle at frontier dot com>]

On 11/03/2010 02:26 PM, FX wrote:
> See below for the description of the patch; this take n+1 incorporates suggestions by Michael Meissner and Rainer Orth, with the following exceptions:
>
>    -- As avr.c includes new headers (cpplib.h and cppbuiltin.h), I wanted to update its dependencies in the target configuration file (t-avr), but to my surprise, this file doesn't contain any mention of avr.o. In fact, I failed to find any by grepping the whole tree, so I'm a little unsure how this can work (and apparently it does). Could the maintainers help me here?
>
>    -- Michael is worried about splitting all this stuff:
>
> > > Unless I don't see what you're talking about, this is not possible: the Fortran front-end is not linked with the *-c.c files, only with *.c, so the language-independent functions need to be moved there.
> >
> > Yes, but if fortran is going to use the preprocessor, maybe they should be
> > linked in.  I'm just worried about the possibility of a macro getting lost in
> > the movement.
>
>
> Well, we do need some separation between CPP built-in macros that are only relevant for C-family languages (for example, because they depend on flag variables that are only declared for C) and the others. Now that the job is done, was discussed beforehand, and it fixes the regression experienced by Fortran, I'd be glad to just have it work.
>
>
> Tested as indicated below, OK to commit? (needs a global reviewer; pretty pretty please, don't let it bitrot again)  I'd like to highlight that it's nothing conceptualy major, and it'll be easy to fix any eventual fallout.
>
> FX

I have reviewed this patch and I have to agree with FX.  There is nothing here 
that makes these workings more obfuscated then they already are and I think the 
splitting actually makes it easier to understand, ie less obfuscated. 
Considering the lessor evil and that it passes testing, and I would like to 
encourage this patch be approved.

I would like to see specific comments as to why not if not, so we can close on this.

Regards,

Jerry