I’m writing a platform independent I6 extension that uses the glk API, and I’d like to discuss my experiences with infglk.h and make a recommendation:
[rant]Here’s a chronology of events:
- I read through Adam Cadre’s Gull document as a quick overview and refresher on glk/glulx programming. He recommends using infglk, a library that wraps direct glk calls (e.g., @glk 66
with meaningfully named functions (glk_stream_open_file();). Seems like a good idea that will improve code readability. - I visited the ifarchive and found infglk.zip, by John ‘katre’ Cater, among the I6 library contributions. The archive contained: func.txt (a list of glk function specifiers and the functions to which they correspond, taken from zarf’s glk spec), glk.h (zarf’s glk header, unmodified), glk2inf.pl (a perl script by katre, the meat of this extension), infglk.h (the output of the glk2inf.pl tool), and test.inf (a small test program that includes infglk.h). The idea is to run glk2inf.pl with func.txt and glk.h as input, producing infglk.h, which can then be included in one’s I6 project.
- I noticed that infglk was 5 years old and based on glk version 0.7.3. I wondered if the glk api had changed in the interim. I checked the archive and saw that a newer version of glk, 0.7.4, now existed. The changes appeared to be minimal and backwards compatible, but I thought “why not use the latest and greatest if possible?”
- I downloaded glk.h and the glk spec for 0.7.4, created a new func.txt from the spec, ran glk2inf.pl, and produced a new infglk.h based on glk 0.7.4.
- I wondered why this wasn’t on the ifarchive and considered putting it there myself. I figured that I should probably get permission from katre if I wanted to upload a zipfile containing his tool along with the new infglk.h, so I searched these forums for any trace of him or discussion of infglk.h.
- I found some discussion circa 2011 (“remember to get the latest infglk.h, not the one in the IF Archive but the one in zarf’s github thing”) indicating that infglk had been incorporated into I7’s I6 template layer and that zarf was now maintaining a github repo containing a tool called parse_dispatch.py that replaces glk2inf.pl and produces a similar infglk.h.
- I experienced a complete failure to be surprised as I reflected on my recent experiences locating the latest versions of various I7 extensions.
- I grabbed the infglk.h from zarf’s github repo and saw that it contained some new API elements that appear to be destined for a future 0.7.5 glk release. Pleased that I had now located the actual latest and greatest, I incorporated it into my project.
- Compiling my project, I discovered that the parse_dispatch.py version of infglk.h has some drawbacks relative to the old glk2inf.pl version.
[list]
[*] It’s doesn’t have a System_file; declaration in it, so compilation produces many warning about unused constants and functions - It doesn’t conditionally compile based on whether TARGET_GLULX is defined. Not a big deal, since the inclusion site can be protected instead, but it’s still 2 lines of code to write.
- It doesn’t contain guards against multiple inclusion. This is more of a big deal from the standpoint of an extension author, because I can’t control what my clients will do. I can tell them not to include infglk.h because my library does, or tell them that, if they do, they should include it before including my header, but it’s one more item on a list of fiddly “in order to use this extension, you need to do x or not do y” things, when I’d rather that the list consist entirely of “include my header file and go about your business”.
[/:m]
[] So, I edited the new infglk.h to include these things, leaving me with this Frankensteinian hybrid of the preamble of the old infglk with the body of the new infglk rather than the purely autogenerated file that I’d like. It also makes it slightly less clear what I need to do for licensing/compliance in order to ship the resulting infglk.h file with my extension other than to clearly state what I’ve done, apply credit liberally, and cross my fingers.[/*:m][/list:u][/rant]
Reading through more of the “infglk” search results here, I came across a post from DavidG in which he says, for slightly different reasons than my own:
Yes, can we? It’s already incorporated into I7. Why not integrate it into the I6 library and make the lives of I6 programmers easier as well?
I think there’s also a broader question about the role of I6 and its library these days. Does it exist strictly to support I7, or does it exist as language in its own right that should continue to evolve (in a way that’s considerate of I7’s dependence on it) to support traditional (non-natural language) IF programming targeted at the z-machine and glulx.