Ramsay Jones wrote: > 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. That does make sense. Perhaps “traditionally” was not the right word; I was just looking at common practice. I’ve just never seen -O put into LDFLAGS, for example, and I think most people would expect setting CFLAGS=-O0 to affect the linker, too. > Jonathan Nieder wrote: >> 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 [etc] >> >> What do you think? > > I think I am missing something, since I don't see how this relates to > my patch! I suspect the problem comes from my unfamiliarity with MSVC. By analogy with GCC, I assumed that any parameter is intended for the preprocessor, the linker, or the frontend/both. In other words, I was assuming flags for the compiler proper can be safely passed to the linker, and that /Zi must be for the preprocessor-using stages only. CFLAGS tends to contain front-end arguments used for all stages of translation. What does /Zi do? Searching online reveals: - it means “enable debugging information” - weakly implies /debug for the linker - overrides /Z7 and /Zd, and is overridden by them - is incompatible with /MP - is among the prerequisites for /dlp and for /Gm Maybe clink.pl should use “cl.exe /link” instead of “link.exe” and this problem would go away. -- 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