Another issue with diagnostic format-checker
Kaveh R. Ghazi
ghazi@caip.rutgers.edu
Sat Jul 19 16:57:00 GMT 2003
> From: Gabriel Dos Reis <gdr@integrable-solutions.net>
>
> "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
>
> | You must define GCC_DIAG_STYLE to __gcc_cdiag__ before including
> | toplev.h.
>
> Now, this is rendering the whole machinery inclusion order dependent.
> A recipe for disaster.
>
> | You can either do it explicitly or by including c-tree.h
> | (as most other C frontend file do.)
>
> Instead of insisting on hardwiring GCC_DIAG_STYLE (thus opening the
> door for all kinds of nightmarre) in files, I'll reiterate what I
> suggested earlier:
>
> GCC_DIAG_STYLE should be set by each individual front-end, directly.
>
> We already do this for other flags.
> An obvious way to do that is for each front-end Makefile to use
> something like
>
> -DGCC_DIAG_STYLE=__gcc_xxx__
>
> when compiling files used in that front end. That way, we don't depend
> on inclusion order, or file inclusion otherwise unnecessary.
>
> There might be other more elaborated ways to accomplish the same thing, but
> relying on inclusion other is NOT viable.
>
> If you agree on the above scheme, I'll try to produce a patch.
> -- Gaby
I agree inclusion order dependencies is an issue in need of solving.
Though perhaps "disaster" and "nightmare" is a bit overwrought. :-)
Your idea sounds fine, but I'm not sure where a good place to stick
the -D flag would be. For the cp/ and objc/ directories we could put
it in cp-warn/objc-warn, but given the "warn" in the name it sounds
like we're innappropriately overloading those spots. I don't see
anywhere we could easily place the C frontend -D flag. We might have
to invent a place, in which case we should invent and appropriately
name a respective spot for all three languages.
--Kaveh
--
Kaveh R. Ghazi ghazi@caip.rutgers.edu
More information about the Gcc
mailing list