Jonathan Nieder wrote:
> Ramsay Jones wrote:
>
>> LINK : warning LNK4044: unrecognized option '/Zi'; ignored
>>
>> In order to suppress the warning, we refrain from passing the
>> $(ALL_CFLAGS) macro to the linker.
>>
>> Note that, should it be necessary in the future, an option
>> intended for both the (front-end) compiler and the linker can
>> be included in both CFLAGS and LDFLAGS.
>
> I think traditionally CPPFLAGS is meant to be used for the purpose
> you are describing (see [1] for example).
Really? I thought that the general scheme was something like:
- LDFLAGS is for options which only affects the operation of
the linker (e.g. -L).
- CPPFLAGS is for options which only affects the operation of
the C pre-processor (e.g. -I, -D, -U)
- CFLAGS is for options which only affects the operation of
the compiler proper.
If an option affects multiple phases, then (one option) is to include
it into each of the above macros to which it applies.
In practice, of course, I've yet to see a Makefile which faithfully
implements the above scheme. ;-)
Also, the last time I was forced to use automake (yuck), I noticed that
it passed CPPFLAGS to the linker; I consider this to be a bug in
automake. :-P
[CFLAGS et. al. are also supposed to be user settable ...]
> I realize that the Makefile does not currently use the terms this way:
> making it consistent would require
>
> . s/BASIC_CFLAGS/BASIC_CPPFLAGS/, except that the
>
> BASIC_CFLAGS += -Kthread
>
> settings should probably stay as-is
>
> . Windows BASIC_CFLAGS would probably need to be split:
>
> BASIC_CFLAGS = -nologo
> BASIC_CPPFLAGS = -I. -I../zlib ... -DWIN32 ...
>
> . s/COMPAT_CFLAGS/COMPAT_CPPFLAGS
>
> What do you think?
I think I am missing something, since I don't see how this relates to
my patch!
I'm sure the misunderstanding is mine; sorry to be so dense!
ATB,
Ramsay Jones
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html