C option processing, header inclusion ordering dependencies

C option processing, header inclusion ordering dependencies

[Mike Stump]

In doing up the mods for the constant wide int code, we found a nasty including ordering problem that seems only tangentially related to our code.  In options.h this is generated:

/* Anything that includes tm.h, does not necessarily need this.  */
#if !defined(GCC_TM_H)
#include "input.h" /* for location_t */
bool                                                                  
common_handle_option_auto (struct gcc_options *opts,                  
                           struct gcc_options *opts_set,              
                           const struct cl_decoded_option *decoded,   
                           unsigned int lang_mask, int kind,          
                           location_t loc,                            
                           const struct cl_option_handlers *handlers, 
                           diagnostic_context *dc);

and produces a nasty dependency on include ordering that's annoying to track down as it fails only in the C++ bootstrap.  If one includes tm.h first, then c-opts.c doesn't compile with C++ but does with C.  If one adds a #include "options.h" before the #include "tm.h", then things are fine.  :-(  Changing the contents of the include based upon something as trivial as the include ordering is, nasty.  So, that said, in a new file we'll be submitting shortly to handle wide int constants (wide-int.h), we have a #include "tm.h", and we don't use options.h, but without a #include of options.h first, c-opts.c won't compile.  Needless to say, tree.h will include the wide-int.h header file...  I'm sure this was engineered to work in come fashion, but, that escapes me, what is the correct dance ensure the prototypes in options.h are present?  Include options.h at the top of c-opts.c, to ensure it comes before tree.h (which is the file that includes the wide-int.h header, include options.h in wide-int.h?

Re: C option processing, header inclusion ordering dependencies

[Joseph S. Myers]

On Tue, 17 Jul 2012, Mike Stump wrote:

> In doing up the mods for the constant wide int code, we found a nasty 
> including ordering problem that seems only tangentially related to our 
> code.  In options.h this is generated:

Maybe such prototypes in options.h, that don't actually depend on anything 
in the .opt files, would better go in opts.h (unconditionally)?  I think 
that should avoid the ordering issue you describe.

-- 
Joseph S. Myers
joseph@codesourcery.com