[I7-2027] [Mantis 2064] Include directive should be case-insensitive

[curiousdannii-testing]

Reported by : zarf

Description :

Quoting comment sent to me on Github:

Some systems (I.E. Linux) can use case-sensitive file systems. This means that in the same directory, files that have the same name but with different cases can exist; e.g. Parser.h and parser.h.

What this means, is that when an inform source file assumes case-insensitive filesystems and Include s with a different casing than what the file is called on the (case-sensitive) system, the build fails. For example (using a fresh clone of inform6lib and the shortest "ruins.inf" example from DM4 §4):

~/devel/inform/ruins
% inform +/home/chameleon/builds/inform6lib -G ruins.inf
Inform 6.34 (28th June 2018)
line 4: Fatal error: Couldn't open source file "/home/chameleon/builds/inform6lib/Parser.h"
Considering the prevalance of Include "Parser"; and the fact that probably most IF developers will assume case-insensitive filesystems on Windows or OSX, it'd be great if Inform on Linux could compile case-insensitively.

A workaround is renaming or creating symbolic links.

Steps to reproduce :

Additional information :

imported from: [Mantis 2064] Include directive should be case-insensitive

• status: Closed
• resolution: Resolved
• resolved: 2022-04-10T04:06:52+10:00
• imported: 2022/01/10

[curiousdannii-testing]

557058:4c095ffd-6d6f-47ce-9e73-77c613347b86:

Comment by zarf :
Historical background:

In the early days, the I6 library files were distributed with these filenames:

English Grammar Parser VerbLib infix linklpa linklv parserm verblibm

Some files were capitalized, some were not, but the capitalization matched the DM example code of

Include "Parser";

When AcornOS and MacOS Classic faded into history, I think we switched to adding the .h suffix, but with the same capitalization:

English.h Grammar.h Parser.h VerbLib.h infix.h linklpa.h linklv.h parserm.h verblibm.h

That's how Graham's last I6lib release (6/11) was set up.

But Linux users have always had a predilection for both case-sensitive filesystems and all-lower-case filenames, and I think that the Linux packages for I6lib have leaned that way. The current (6/12) repo at https://gitlab.com/DavidGriffith/inform6lib has switched over to all lower case. This causes problems for people attempting to start a new I6 project from scratch.

[curiousdannii-testing]

557058:4c095ffd-6d6f-47ce-9e73-77c613347b86:

Comment by zarf :
My commentary:

I always feel nervous about reinterpreting a user's filenames. However, the compiler already adds the ".h" suffix, in a long-standing attempt to adapt to platform filesystem conventions. (From MacOS Classic, which didn't really believe in file suffixes.)

So it's not a stretch to try to read files case-insensitively too.

The implementation is a bit of a pain, though. Unlike the suffix-adding code, this would have to be checked on the fly. Either:

• Read the entire directory, case-insensitively match filenames, call fopen() on the best pick;
  or
• Call fopen(), see if it failed, if so downcase the filename and try fopen() again.

(The latter option is not truly case-insensitive, of course, but it handles the problem we've got.)

[curiousdannii-testing]

557058:4c095ffd-6d6f-47ce-9e73-77c613347b86:

Comment by zarf :
Of course when I say "downcase the filename" I mean "downcase the last segment of the pathname".

Note to myself: the set_path_command() function in inform.c does some downcasing, but it doesn't affect filenames. It's just used on the "include_path=" part of the argument.

[curiousdannii-testing]

557058:4c095ffd-6d6f-47ce-9e73-77c613347b86:

Comment by DavidG :
I'd like to take on implementing the second option.

[curiousdannii-testing]

61eedb62875fc10070240916:

This bug tracker no longer tracks Inform 6.