SZEDER Gábor wrote: > On Tue, Oct 16, 2018 at 02:54:56PM -0700, Jonathan Nieder wrote: >> SZEDER Gábor wrote: >>> Our Makefile has lines like these: >>> >>> CFLAGS = -g -O2 -Wall >>> CC = cc >>> AR = ar >>> SPATCH = spatch [...] >>> I'm not sure what to do. I'm fine with updating our 'ci/' scripts to >>> explicitly respect CC in the environment (either by running 'make >>> CC=$CC' or by writing $CC into 'config.mak'). Or I could update our >>> Makefile to use '?=' for specific variables, but: >> >> That's a good question. I don't have a strong opinion myself, so I >> tend to trust larger projects like Linux to have thought this through >> more, and they use 'CC = cc' as well. > > I don't think Linux is a good example to follow in this case, see e.g. > 6d62c983f7 (Makefile: Change the default compiler from "gcc" to "cc", > 2011-12-20) (in short: Git is supposed to be buildable with compilers > other than GCC as well, while Linux not really, so they can hardcode > 'CC = gcc'). Nowadays Linux builds with clang as well. People also have other reasons to override the CC setting (cross-compiling, etc) and to override other settings like CFLAGS. > Also, the projects I have on hand usually have 'CC = gcc' hardcoded in > their Makefiles, too, but those Makefiles were generated by their > ./configure script (which in turn by ./autogen.sh...), and those tend > to write CC from the environment into the generated Makefiles. Yes, I think that's what makes travis's setup normally work. It makes sense to me since ./configure is expected to have more implicit or automatic behavior. For "make", I kind of like that it doesn't depend on environment variables that I am not thinking about when debugging a reported build problem. When building Git without autoconf, the corresponding place for settings is config.mak. Would it make sense for the ci scripts to write a config.mak file? Thanks, Jonathan
