Re: specs: *predefine oddity

[Michael Meissner <meissner at cygnus dot com>]

On Tue, Nov 02, 1999 at 04:37:08PM -0500, Gavin Romig-Koch wrote:
> Michael Meissner writes:
>  > On Tue, Nov 02, 1999 at 06:45:57PM +0100, Ralf Corsepius wrote:
>  > > 3)
>  > > *predefines:
>  > > -Dfoo -D__foo__
>  > > Expands to this weird and unnecessarily lengthy line:
>  > > -Dfoo -D__foo__ -D__foo__ -D__foo__ -D__foo
>  > > 
>  > > Is this really the desired behaviour ? Is it documented somewhere and
>  > > can we rely on this behaviour to be kept in future gcc-versions?
>  > 
>  > Yes, it is desired beahvior.  
> 
> Michael's comments are all correct, but I assumed Ralf's question
> was not about the treatment of -Dfoo, but about the treatment of
> -D__foo__ (although it might have been about both).
> 
>  > Yes, it is documented (look for the documentation for
>  > CPP_PREDEFINES in the tm.texi part of the manual).
> 
> GCC's treatment of -D__foo__ is not documented (at CPP_PREDEFINES 
> at least).  (Nor is it documented that -Dfoo will also produce
> -D__foo.)  This is unfortunate.  Documenting the behavior of
> CPP_PREDEFINES more fully would be an easy beginners project
> for someone looking for something to do (you'd need to consult
> the code in gcc to be sure of it's behavior).

I agree about documenting defining __foo.  However, before I posted, I did
check the fine manual (tm.texi):

	@item CPP_PREDEFINES
	Define this to be a string constant containing @samp{-D} options to
	define the predefined macros that identify this machine and system.
	These macros will be predefined unless the @samp{-ansi} option is
	specified.

	In addition, a parallel set of macros are predefined, whose names are
	made by appending @samp{__} at the beginning and at the end.  These
	@samp{__} macros are permitted by the ANSI standard, so they are
	predefined regardless of whether @samp{-ansi} is specified.

	For example, on the Sun, one can use the following value:

	@smallexample
	"-Dmc68000 -Dsun -Dunix"
	@end smallexample

	The result is to define the macros @code{__mc68000__}, @code{__sun__}
	and @code{__unix__} unconditionally, and the macros @code{mc68000},
	@code{sun} and @code{unix} provided @samp{-ansi} is not specified.

 
> I suspect the reason that the treatment of -D__foo__ is not documented
> is because no-one expects -D__foo__ to be put in CPP_PREDEFINES, but
> that instead it would be put into CPP_SPECS.  If you need a -D__foo__
> but don't want a -Dfoo, put the -D__foo__ into CPP_SPECS not 
> CPP_PREDEFINES.  This too could be added to the docs.
> 
> Another possible issue here is that while we document the macros
> that produce the default specs, we don't document the actual specs.
> I don't know how many people mess with the specs file but not with
> the target macros, but perhaps there are enough of them to justify
> documenting the specs themselves separate from the target macros
> that produce them.  Someone could reorganize the doc so that, for
> example, the current doc for CPP_PREDEFINES is moved into new doc
> for the spec *predefines, and the doc for CPP_PREDEFINES would be
> changed to indicate that it's value is the initial value for
> *predefines.

I thought I remember a patch going by to document the specs language.  I agree
they should be documented somewhere besides gcc.c.

> Anyway enough rambling, thanks for the note Ralf, and hopefully
> we've given you enough to go forward on.
> 
>                                          -gavin...

-- 
Michael Meissner, Cygnus Solutions
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886
email: meissner@cygnus.com	phone: 978-486-9304	fax: 978-692-4482