This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Another issue with diagnostic format-checker
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
> "Zack Weinberg" <zack@codesourcery.com> writes:
>
> | Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
> |
> | > | > It removes the inclusion order dependency and lets each front end say
> | > | > what its "set" looks like.
> | > |
> | > | So does putting #defines in the relevant source files.
> | >
> | > No, it does not. See previous discussion with Kaveh.
> |
> | Your assertion is a contradiction in terms, because -DFOO=bar is
>
> No it is not, see below.
>
> | precisely equivalent to "#define FOO bar" appearing on the first line
> | of the source file.
>
> but it removes the inclusion order dependency.
But it doesn't! There is still an ordering dependency between the
#define and the #include. All you've done is apply magic to make it
harder to get the ordering wrong, at the cost of comprehensibility
(since the #define is hiding in a magic location) and maintainability
(you have to add crap to the Makefile).
> | The only reason to prefer -DFOO=bar is if the
> | value of 'bar' is determined by the Makefile, but you have said that
> | it is not.
>
> Where?
When you said that you didn't intend to compile files twice.
Perhaps I was unclear: if the literal string '-DFOO=bar' appears in
the makefile, that's an undesirable use of -D, because it could have
been a #define in the source code instead. If the text in the
makefile is '-DFOO=$(FOO)', and there's a variable definition FOO=bar
elsewhere in the makefile (and that variable actually *varies* on some
condition, otherwise constant propagation reduces this to the
preceding case), then it is an appropriate use of -D.
No, I don't like -DIN_GCC either.
zw