Re: [PATCH 4/4] Makefile: Don't pass $(ALL_CFLAGS) to the linker

Jonathan Nieder wrote:

Ramsay Jones wrote:

quoted

    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