Compiling a 6M62 project in Inform 10.1.2 problem

The project’s all been built in 6M62 so far. I thought I’d try compiling it in 10.1.2 (Mac) using the project setting 6M62 and see how it went.

It translated the source okay, then failed with the error message that begins like so:


Translating the Source - Failed

The application ran your source text through the Inform 7 compiler, as usual, and it found no problems translating the source. Something must have gone wrong all the same, because the second stage of the process - using the Inform 6 compiler to turn this translated source into a viable story file - turned up errors. This should not happen. The errors are written out on the Console tab, but will only make sense to experienced Inform 6 users (if even to them)…

The three specific console errors it gave all seem to be coming from Mark Tilford’s Automap (the version updated for 6L02: extensions/Automap.i7x at master · i7/extensions · GitHub)

Inform 6.41 for MacOS (22nd July 2022)
File "/Users/wade/Desktop/andac095-10.inform/Build/auto.inf"; Line 983	# Error:  use 'Array' to define arrays, not 'Global'
>   Global Automap_links -->
File "/Users/wade/Desktop/andac095-10.inform/Build/auto.inf"; Line 983	# Error:  Expected ';' but found MAP_ALLOC_AREA
>   Global Automap_links --> MAP_ALLOC_AREA
File "/Users/wade/Desktop/andac095-10.inform/Build/auto.inf"; Line 983	# Error:  Expected directive, '[' or class name but found MAP_ALLOC_AREA
>   Global Automap_links --> MAP_ALLOC_AREA

I guess I hoped a thing that what worked in original 6M62 would work in, well, whatever this sort of legacy mode is actually called, without trouble. But I also half-expected it might not.

I’d appreciate it if someone could have a look at that bit of the extension and maybe indicate tweaks that might make 10.1.2 happy? That is (or whether or not?) 10.1.2’s failure on this is actually a bug in 10.1.2. Thanks


1 Like

I think the issue is arising due to changes in the I6 compiler, which has had some upgrades since the original 6M62 release, and not specifically from anything in I7. It looks like a new error is being thrown due to an I6 inclusion in the extension.

All three errors seem to stem from the first noted problem, which is incorrect use of Global to declare an array. This may have been a warning or just accepted in earlier compiler versions.

Up toward the top of the extension code (lines 40-53) is the following (with comments added):

#ifdef AUTOMAP_ALLOCATE_STATIC;					 ! <-- from I7 use option "Use automap static allocation"
	Array Automap_Chars -> MAP_ALLOC_AREA;
	#ifdef AUTOMAP_HYPERLINKS;					 ! <-- from I7 use option "Use automap hyperlinks"
		Global Automap_links --> MAP_ALLOC_AREA; ! <-- error line
	Global MAP_ALLOC_AREA = 0;
	Global Automap_Chars = 0;
	Global printed_nomalloc_message = 0;
		Global Automap_links = 0;				 ! <-- related

It may be sufficient to change line 44 to

		Array Automap_links --> MAP_ALLOC_AREA; ! <-- adjusted line

to resolve the error, but I’m not 100% certain since I haven’t analyzed the rest of the code.


Argh! I always tell people that you can use the latest version of I6 without worrying about backwards compatibility, but here is a case where you can’t.

Yes, that’s sufficient. The use of Global arr --> ... to create an array is very obsolete; I think it was deprecated in Inform 6.0.0. I thought it was safe to remove it from the compiler. I guess it lingered in this one extension.

Sorry about that.


Thanks all. I made the adjustment and it compiled.

I’m not on my main multi-core M1 this week. I notice when I compile the game using the native 6M62 app, on my laptop or the much newer M1, it takes exactly the same time to compile on either computer. On the M1, I can see it basically maxes out 1 of 8 cores to do its work.

I just wondered if anyone happens to know if 10.1 makes use of multiple cores on a Mac, and would thus speed up compile time, when I get back to it?


1 Like

The core Inform compiler cannot use multple cores to speed up compilation, sadly. The problem of getting a compiler that processes a project as a whole to use multiple cores is extremely difficult, as there’s no obvious way to divide the problem into parts that can be handled in parallel in an efficient way.


Thanks for the explanation.


1 Like

Yeah, to the best of my knowledge it does use multiple cores when there are multiple units to be compiled in parallel…but after the initial build, things like WorldModelKit don’t have to be compiled again, and the only thing that needs to be rebuilt is your own source.