As lovely as the official Inform 7 IDEs are, I’m an old-school Unix nerd at heart, and I would like to have something like David Griffith’s inform6unix for Inform 7: a way to make the compiler available as a regular command-line tool, putting all its resources and documentation in traditional Unixy locations.
I currently have a solution that mostly works, but the first time I use inform7 to compile a game, it decides it needs to regenerate “EnglishLanguageKit”:
Inform 7 v10.2.0 has started.
I've now read your source text, which is 4542 words long.
I've also read version 2 of Basic Inform by Graham Nelson, which is 10686 words long.
I've also read version 10.2.0 of English Language by Graham Nelson, which is 2330 words long.
I've also read version 7 of Standard Rules by Graham Nelson, which is 35530 words long.
(Building EnglishLanguageKit for architecture 16)
(Building EnglishLanguageKit for architecture 16d)
(Building EnglishLanguageKit for architecture 32)
(Building EnglishLanguageKit for architecture 32d)
The 4542-word source text has successfully been translated. There were 27
rooms and 58 things.
Inform 7 has finished.
(note the various “Building EnglishLanguageKit…” lines)
As of the language extensions reform, EnglishLanguageKit is in the Inform 7 internal nest at Extensions/Graham Nelson/English Language.i7xd/Materials/Inter/EnglishLanguageKit. That is, it’s an internal data file for the compiler, and in a traditional Unixy environment that would be installed in a system-wide location that ordinary users would not be allowed to modify; in this particular case, the Inform 7 compiler crashes when it tries to write the kit and fails. So, I’d like to build EnglishLanguageKit as part of the installation process, so that the Inform 7 compiler doesn’t feel the need to rebuild it.
Looking at the online documentation for Inform’s kit-building tools it seems the following command should do the trick:
inbuild/Tangled/inbuild -build inform7/Internal/Extensions/Graham\ Nelson/English\ Language.i7xd/Materials/Inter/EnglishLanguageKit/
…and sure enough, that command creates pre-compiled Inter bytecode files for all supported architectures. Unfortunately, the Inform 7 compiler doesn’t like them, and still rebuilds them from scratch the first time.
The bytecode files as created by inbuild look like this:
-rw-rw-r-- 1 st 31407 Aug 25 23:24 arch-16.interb
-rw-rw-r-- 1 st 31428 Aug 25 23:24 arch-16d.interb
-rw-rw-r-- 1 st 31413 Aug 25 23:24 arch-32.interb
-rw-rw-r-- 1 st 31434 Aug 25 23:24 arch-32d.interb
…while the ones created by inform7 look like this:
-rw-rw-r-- 1 st 34191 Aug 25 23:25 arch-16.interb
-rw-rw-r-- 1 st 34635 Aug 25 23:25 arch-16d.interb
-rw-rw-r-- 1 st 34619 Aug 25 23:25 arch-32.interb
-rw-rw-r-- 1 st 34641 Aug 25 23:25 arch-32d.interb
You’ll note they’re about 3KB larger, which seems like a significant difference. However, when I use inter to convert them from binary to textual form, the only difference is the “origin” marker that records the path of the source file it was built from, which is about 40 bytes difference.
Clearly there’s something that inform7 is checking to determine whether it needs to rebuild EnglishLanguageKit, and it’s different logic from what inbuild uses. Unfortunately, I can’t figure out what. Does anyone else know?
(I understand this is going quite beyond the intended and supported use-cases of Inform 7, and “stop wanting that” might be the only reasonable response. Still, I figured I’d ask)