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