|Anonymous | Login | Signup for a new account||2020-02-22 11:10 PST|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002064||Inform 6||General||public||2018-07-19 09:12||2019-05-13 05:12|
|Target Version||Fixed in Version|
|Summary||0002064: Include directive should be case-insensitive|
|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):
% 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.
|Tags||No tags attached.|
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
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.
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;
- 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.)
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.
|I'd like to take on implementing the second option.|
|2018-07-19 09:12||zarf||New Issue|
|2018-07-19 09:24||zarf||Note Added: 0004788|
|2018-07-19 09:41||zarf||Note Added: 0004789|
|2018-07-19 09:43||zarf||Note Added: 0004790|
|2019-05-13 05:10||DavidG||Issue Monitored: DavidG|
|2019-05-13 05:12||DavidG||Note Added: 0004857|
|Copyright © 2000 - 2010 MantisBT Group|