Hello, The MinGW project, as you probably know, offers pre-compiled make binaries for Windows. It is built with HAVE_CASE_INSENSITIVE_FS enabled, because it is assumed most Windows users will be more comfortable with this setting.
However, the current implementation of case insensitive rules seems to be too limited, according to some users. They wish to benefit from the case-preserving nature of Windows file systems. For example, something like this came up in a MinGW bug report: === main.S === #define MSG "hello" .asciz MSG ============== When HAVE_CASE_INSENSITIVE_FS is disabled, we succeed: cs-make --debug=vj main.o This program built for Windows32 Reading makefiles... Updating goal targets.... Considering target file `main.o'. File `main.o' does not exist. Considering target file `main.S'. Finished prerequisites of target file `main.S'. No need to remake target `main.S'. Finished prerequisites of target file `main.o'. Must remake target `main.o'. gcc -c -o main.o main.S Main thread handle = 0x000007bc Successfully remade target file `main.o'. However, when HAVE_CASE_INSENSITIVE_FS is enabled: ci-make main.o This program built for Windows32 Reading makefiles... Updating goal targets.... Considering target file `main.o'. File `main.o' does not exist. Considering target file `main.s'. Finished prerequisites of target file `main.s'. No need to remake target `main.s'. Finished prerequisites of target file `main.o'. Must remake target `main.o'. as -o main.o main.s Main thread handle = 0x000007bc main.s: Assembler messages: main.s:2: Error: junk at end of line, first unrecognized character is `M' ci-make: *** [main.o] Error 1 The case insensitive version matches main.S to the ".s.o" rule, which is different from the ".S.o" rule. See the full discussion in: http://sourceforge.net/tracker/index.php?func=detail&aid=1928876&group_id=2435&atid=102435 Now, users could be advised to either fix their makefiles to not depend on case, or use a version of make compiled with case insensitivity disabled. But perhaps they could be spared the trouble, if the same binary could work transparently for them as well. After some discussion, Keith suggested the following: > Consider *all* targets as fundamentally case-insensitive, but first > attempt to resolve them as case-sensitive, falling back to the > case-insensitive behaviour only if the case-sensitive match remains > unresolved. At that point, I stepped in and offered to help implementing such a solution. I like to call it "case-aware file matching", where "aware" is a middle term between "insensitive" and "sensitive". I began by looking at the update_file_1 function, the pattern_search function and the directory cache. A plan would involve converting some of the compile time checks on HAVE_CASE_INSENSITIVE_FS to runtime checks, adding a "case" parameter to the corresponding function. And perhaps having a second directory cache with case insensitive ordering. Regards, Cesar _______________________________________________ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
