FWD: HAVE_CASE_INSENSITIVE_FS

[Paul Smith]

Hartmut: I'm forwarding this to the make-w32 list, which is where most
of the folks who would know something about this are reading (I hope).
I'm happy to comment on the feasibility (or not) of various solutions
but I don't use this flag, or the systems that it's needed for, so I'm
not sure what the right solutions might be.

Hopefully this is OK.  I have made a few comments below.

Eli/et.al.; any comments on this?

Hartmut Becker <address@hidden> writes:

> Hi Paul,
> 
> I have some comments on gnu make and case sensitive file systems.  
> Before I get to the details, these comments are not VMS-specific.
> 
> Using the strcache for all filename strings (a change from 2007-03-19)
> somehow breaks the HAVE_CASE_INSENSITIVE_FS. But maybe it was broken
> anyway.
> 
> With the change there is no need for "downcasing" the filename
> strings: all the compares (and the hashing) are - or should be - done
> with case insensitive compares (ISTRING_COMPARE and ISTRING_HASH_1,2).
> 
> However there are some case sensitive compares in implicit.c (streq
> and strneq) which seem to need a HAVE_CASE_INSENSITIVE_FS and case 
> insensitive compares (or a STRIEQ and STRNIEQ similar to 
> ISTRING_COMPARE, etc.).
> 
> I didn't try to figure out if all streq and strneq need to have that, 
> but if I change the one for "Check that the rule pattern matches the 
> text after the stem." it fixes the problem I saw when a modified
> source didn't trigger a rebuild.
> 
> So for a test I changed implicit.c, removed all the filename
> downcasing and make worked as expected.
> 
> I'm not sure if that is the solution. Although this seems to be the 
> right thing, there are two problems with it:
> 
> a) .suffixes is accepted and seen as .SUFFIXES (there may be more 
> targets like that)

Hm.  Well, according to the POSIX standard any target starting with "."
is technically reserved for extensions by make (IIRC).  Maybe any target
starting with "." could just be treated specially and compared in a
case-sensitive way even for case-insensitive filesystems.  That should
be pretty easy to encapsulate into a macro.  Note there are many more
special targets like this, not just .SUFFIXES.

Or we could just ignore it and allow both .suffixes and .SUFFIXES on
case-insensitive systems.

> b) The actions shown have a mix of lower- and uppercase names with no 
> obvious reason for some strings being in lower- and others in
> uppercase characters.
> 
> a) and b) show with the CVS version prior to my patches as well. So it
> is not new with any of my recent changes, including the ones for the 
> above test.
> 
> Problem a). To fix it .SUFFIXES needs to be excluded from insensitive 
> compares. That's probably expensive to do.
> 
> In the current CVS code, for is  code for "downcasing" all filenames, 
> excluding ones which start with a dot. That's not enough, here. The
> case insensitive compares are still there and needed: there may be
> mixed cases in a dependecy.
> 
> Problem b). The strings, which are shown as actions, come from the 
> makefile or from reading the directory, whatever comes first. But
> there is also a caching of filenames while reading the directory. When
> main.c is searched A.C etc. may be found in the directory before a.c
> is seen in the makefile. Then that uppercase name shows in the action.
> This is not an error, it is just confusing.
> 
> Downcasing all filenames including the ones read from the makefile
> seems a way to fix this. But then there is no need for case
> insensitive compares and hashes. Additionally, excluding .SUFFIXES
> from downcasing, will fix a), too. the disadvantage is, this change
> needs a lot of conditional code with HAVE_CASE_INSENSITIVE_FS.
> 
> The other "fix" is to just downcasing the shown action line. Looks
> like cosmetics but that's exactly what's needed to avoid the
> confusion.
> 
> So the easiest fix for a) and b) seems to keep the case insensitive 
> comparing/hashing, to remove all the downcasing and to lowercase the 
> shown action line. However, this keeps the case insensitive .SUFFIXES.

I definitely don't like downcasing the shown action line.  Having a
case-insensitive FS doesn't necessarily mean that EVERYTHING on the
command line is case-insensitive, and having make display a command
string that is different than the one it will invoke seems wrong to me.

One thing we could do, possibly, would be to downcase the contents of
the automatic variables like $@, $<, etc. when make creates them.  This
would mean that BOTH the command line printed AND the command sent to
the shell would have downcased filenames but that would work in a
case-insensitive filesystem.

The other thing to consider is filesystems like Windows which are, I
believe, case-insensitive but case-preserving.  That means that the user
can actually see a difference between somefile.c and SomeFile.c even
though these refer to the same file.  It would be nice, in situations
like this, if make would print the filename in the case that is used on
the filesystem.  I don't know if this is possible; definitely the
standard POSIX stat(2) does not return the filename in struct stat but
perhaps there's some extension available that lets us know the actual
filename.  If this is hard it's probably not worth it.

> Finally, HAVE_CASE_INSENSITIVE_FS is enabled by default for VMS and 
> Amiga. It makes some sense for MS Windows but there it is disabled by 
> default.