Bugzilla Bug 116406

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 an attachment (id=75341) [edit]
gargoyle-20051002.ebuild

Created an attachment (id=75342) [edit]
20051002-fmod-glkloader.patch

Created an attachment (id=75343) [edit]
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 :-(