DavidKinder / Windows-Inform7

Front-end for the Windows version of Inform 7.
http://inform7.com/
Artistic License 2.0
70 stars 10 forks source link

Move Inform build infrastructure from Cygwin to MinGW64 #70

Closed DavidKinder closed 1 year ago

DavidKinder commented 1 year ago

This is not strictly a task related the Windows front-end, but here is a convenient place to record it.

The Inform compiler is now built with clang, but Cygwin only supplies clang version 8, which was released in 2019. MinGW-w64 comes with clang 16, which is the current version. If possible, the build should be switched from Cygwin to MinGW-w64 to use this up to date clang.

DavidKinder commented 1 year ago

Instructions so far:

DavidKinder commented 1 year ago

Most of the Inform system builds with MSYS2 (with a lot of warnings). The first real problem is building Glulxe for the test harness: this defines OS_UNIX for the OS-dependent code, which relies on random() being available. Even worse, the test harness assumes that all versions of random() produce the same output, given the same seed.

To fix this Glulxe should really be built with a fixed random number generator. There is already one in the Glulxe code.

Update: fixed by PR https://github.com/ganelson/inform/pull/105

DavidKinder commented 1 year ago

A further problem that is already present, but a more recent clang makes more obvious, is that places in the code assume that a long integer is big enough to hold a pointer type, but in the usual memory model for Win64, this is not correct.

The only place this occurs in inweb is in inweb/foundation-module/Chapter 2/Streams, where it is assumed that a printf specifier of %x and an argument cast to (long int) is sufficient to print out a representation of a pointer. For C99 the correct printf specifier would be %p.

Update: fixed by PR https://github.com/ganelson/inform/pull/103

DavidKinder commented 1 year ago

Build infrastructure now changed to MSYS2.