GLK is a library interface for programming cross-platform interactive fiction interfaces. Gargoyle is a typographically beautiful implementation of this interface. It PROVIDEs virtual/glk (cf. bug #116061). The library itself is compiled as a shared object to permit usage of glkloader (a wrapper glk library that allows selection of implementation at runtime, provided in bug #116062).
Created attachment 75341 [details] gargoyle-20051002.ebuild
Created attachment 75342 [details, diff] 20051002-fmod-glkloader.patch
Created attachment 75343 [details] gargoyle.rc
Quite the other way around.
Since I'm preparing an ebuild for Jif, I may as well have a look at this one...
duh, forgot to assign it to me....
Just added gargoyle to Portage. Discarded the gkloader patch for now as it breaks the compilation of the gargoyle interpreter, which is needed by JIF. Will see if I can add it later...
Just out of curiousity but did you get permission from the games team before adding a package in which we're responsible for it if you cannot be found? Also, this looks like a library, not a game engine.
Er... no, I asked no permission. I listed myself as package maintainer, so this shouldn't be an issue. As for not being found, I don't know. I spend most of my time in front of my monitor, so availability is not a problem. I'm going to take care of this package, anyway. To answer your second question, gargoyle is a game engine: it is an interpreter for interactive adventures (like frotz, but not limited to text adventures). An example adventure that can be played using this interpreter can be found at http://slade.altervista.org/?Giochi:Little_Falls (Italian site, but I'm sure English ones exist as well). I tou think I broke some rule/etiquette, feel free to contact me :-)
Gargoyle _is_ a library. True, it is bundled with several interpreters preconfigured to link it and use it, along with a wrapper script which tries to call the correct interpreter given a story file, but it's still a library. My ebuild doesn't even install (or compile) the interpreters or the script, just the library configured to be dloaded (as to work with glkloader).
The way you put it in Portage is really bad. You compile and install the _bundled_ interpreters, statically linked with the library. I have taken the utmost care to keep everything nicely separated, ie. the library(ies) and the interpreters, and choosable at runtime. You just took the easy way, used the whole blob bundled with gargoyle and looked no further. Apart from being ugly, this solution makes the user unable to have, for example, text interface in glulxe and frotz. (And, of course, conflicts with any later glulxe or frotz standalone packages that may come.) Please use my original ebuild, along with the one from #116063 (glulxe, useful for example for the 'little falls' story You cite), #116062 (glkloader, the library that allows choosing glk library at runtime; you can remove the reference to xglk (#116061) if you don't want to import that, just gargoyle alone is sufficient atm) and possibly #117932 (nitfol z-machine engine),
I know. I'm not finished with these ebuilds yet. Neither I marked any package as stable, nor these bugzilla entries as fixed. Just give me a little time ;-)
After a lot of time, some issues resolved, some others not, I decided against merging this set of changes into Portage. The main point is that I find this solution a bit overkill and too complicated, while simpler ones are already in Portage. Sorry :-(
