From: Junio C Hamano Date: Fri, 13 Sep 2013 22:06:42 GMT Subject: Re: [PATCH] git-compat-util: Avoid strcasecmp() being inlined Message-ID: In-Reply-To: Sebastian Schuberth writes: > On Fri, Sep 13, 2013 at 10:01 PM, Junio C Hamano wrote: > >>> I don't like the idea of introducing a compat/mingw/string.h because >>> of two reasons: You would have to add a conditional to include that >>> string.h instead of the system one anyway, >> >> With -Icompat/mingw passed to the compiler, which is a bog-standard >> technique we already use to supply headers the system forgot to >> supply or override buggy headers the system is shipped with, you do >> not have to change any "#include ". >> >> Am I mistaken? > > Ah, that would work I guess, but you'd still need the include_next. You can explicitly include the system header from your compatibility layer, i.e. === compat/mingw/string.h === #define __NO_INLINE__ #ifdef SYSTEM_STRING_H_HEADER #include SYSTEM_STRING_H_HEADER #else #include_next #endif and then in config.mak.uname, do something like this: ifneq (,$(findstring MINGW,$(uname_S))) ifndef SYSTEM_STRING_H_HEADER SYSTEM_STRING_H_HEADER = "C:\\llvm\include\string.h" endif COMPAT_CFLAGS += -DSYSTEM_STRING_H_HEADER=$(SYSTEM_STRING_H_HEADER) endif People who have the system header file at different paths can further override SYSTEM_STRING_H_HEADER in their config.mak. That would help compilers targetting mingw that do not support "#include_next" without spreading the damage to other people's systems, I think.