Here's a little ebuild for FrobTADS 0.6. I'm not sure why egamesconf wouldn't work, but it works fine as is. The other interpreter in the tree is QTads, but this one is console based and more current. Bug 73947 is an older curses interpreter. Here's some IF to test with :) http://www.ifarchive.org/indexes/if-archiveXgamesXtads.html
Created attachment 98543 [details] frobtads-0.6.ebuild
Created attachment 98544 [details] TADS3 (license)
Created attachment 104748 [details] frobtads-0.6.ebuild Adds support for the TADS2 and TADS3 compilers, for game development.
The last 0.6 ebuild works fine for version 0.7
*** Bug 217240 has been marked as a duplicate of this bug. ***
(This bug has some wrong entries; "Component" should be "Ebuild" instead of "Games", the "Summary" field should be "frobtads-0.6.ebuild (New Package)" instead of a description of what the package is/does, and "Version" should be "unspecified". I've created a new, correct bug 217240, but it has been marked as a duplicate of this one.) I'm attaching the new ebuild for the latest upstream version (from bug 217240 which was marked as a duplicate for this one). This ebuild uses egamesconf and only appends compiler switches to CXXFLAGS (the package contains both C as well as C++ code so the distinction is important.) Following Gentoo guidelines, I only used KEYWORDS="~amd64 ~x86" since I only tested on those Gentoo versions. However, the package itself is supposed to compile and run on all Gentoo ports, no matter what the architecture or operating system is. In addition to the ebuild, I am also attaching the license. This should probably be /usr/portage/licenses/TADS. Since this is an interpreter and development tool for games, I suppose the right category is "games-engines".
Created attachment 149420 [details] frobtads-0.10.ebuild
Created attachment 149421 [details] Should end up in /usr/portage/licenses/TADS
Uhh... games is the correct component. The other fields are ok/irrelevant. Frobtads 0.10 is still in beta, which is why I haven't updated my ebuild yet. - Why did you add -fno-rtti -fno-exceptions? Is this according to the docs or your own testing? Is this a >=gcc-4.2 issue? In any case, you can take the flag-o-matic inherit out, if it turns out to be acceptable to modify CXXFLAGS directly in this way. Also, why not just add those flags to your Makefiles? - Functionally it's the same, but I have no idea why you would prefer: dodoc doc/AUTHORS doc/BUGS doc/COMPILERS doc/ChangeLog doc/NEWS doc/README doc/THANKS over dodoc doc/{AUTHORS,BUGS,COMPILERS,ChangeLog,NEWS,README,THANKS} - You're missing prepgamesdirs. (unless the games eclass has been recently modified to do this automatically?) Otherwise the changes look OK. Thanks for this nice piece of software!
(In reply to comment #9) > Uhh... games is the correct component. The other fields are ok/irrelevant. > Frobtads 0.10 is still in beta, which is why I haven't updated my ebuild yet. From 0.6 to 0.10 most changes are bug fixes. The main reason to post an ebuild for 0.10 is that 0.6 does not run on 64-bit systems at all; it segfaults. Considering that many people are on AMD64, I think bumping to 0.10 here is a good idea. > - Why did you add -fno-rtti -fno-exceptions? Is this according to the docs or > your own testing? Is this a >=gcc-4.2 issue? No, it's just that the package does neither use RTTI nor exceptions, so those features can be disabled in the compiler for a very slight speed increase and also a very slight size decrease. But it's really not an important thing at all, so I'll remove them. > In any case, you can take the > flag-o-matic inherit out, if it turns out to be acceptable to modify CXXFLAGS > directly in this way. Good point. I don't know though if it's acceptable to access CXXFLAGS directly; at least I didn't find anything in the online docs. > Also, why not just add those flags to your Makefiles? Because not all compilers support them (the package is supposed to also compile with Intel C++ and Sun Studio, for example). Gentoo, on the other hand, is GCC based, so it's guaranteed to support them. > - Functionally it's the same, but I have no idea why you would prefer: > dodoc doc/AUTHORS doc/BUGS doc/COMPILERS doc/ChangeLog doc/NEWS doc/README > doc/THANKS over > dodoc doc/{AUTHORS,BUGS,COMPILERS,ChangeLog,NEWS,README,THANKS} I don't. It's a mistake on my part :) > - You're missing prepgamesdirs. (unless the games eclass has been recently > modified to do this automatically?) I must confess that I don't know what prep(games)dirs does. None of the "write an ebuild" docs and HOWTOs mention it, and since I don't know what it does, I didn't include it. It seemed like most ebuild writers simply copy it from other ebuilds they see just because it's there. In any case, merging and unmerging works just fine with or without prepgamesdirs. Anyway, I added it now along with the other changes plus I quoted the ${P} in src_unpack(). See attachment.
Created attachment 149446 [details] frobtads-0.10.ebuild
Hi Nikos, thanks for the clarification. Prepgamesdirs sets permissions and is documented in the games herd's ebuild guide: http://www.gentoo.org/proj/en/desktop/games/games-ebuild-howto.xml "This function is used to ensure that all files installed by games ebuilds have the proper permissions. This function should be called last in src_install, as it potentially touches every file and directory installed by the ebuild. The purpose of this function is to ensure that the files and directories are writable by ${GAMES_USER}, readable by ${GAMES_GROUP}, and not readable or executable by anyone else." I tried to emerge your ebuild, but ran into the same problem as with mine before I switched away from egamesconf. It fails with a sandbox violation, to wit, "mkdir /usr/games/lib/cf28635". Unfortunately I don't know how to diagnose this error, so hopefully a developer can look at this at some point. Cheers!
Ah, so I thought this might be an autotools issue, so I inherited the autotools eclass and tried: src_unpack() { unpack ${A} use tads2compiler && mv -f t2compiler/* "${P}"/t2compiler use tads3compiler && mv -f t3compiler/* "${P}"/t3compiler cd "${S}" eautoreconf || die "eautoreconf failed" } But still no joy. I'm out of ideas. :\
"It works for me" :P > use tads2compiler && mv -f t2compiler/* "${P}"/t2compiler > use tads3compiler && mv -f t3compiler/* "${P}"/t3compiler What happens if you totally remove those two lines? Other than that, I don't know, it's a pretty normal autotool package; the usual "./configure && make && make install" deal. I've no idea where that "mkdir /usr/games/lib/cf28635" comes from. The package does not provide any kind of lib at all; just executables and data files. Are you up to date? (emerge -auvD world) Could someone else emerge this and test?
Created attachment 149460 [details] emerge --info Those lines aren't triggered if you don't set the use flags, and in any case, they worked fine in my previous ebuild. I seem to remember this same directory being created when I compiled and installed Frobtads outside of Portage with the same configure switches and commands, but it was such a long time ago, I can't be sure. Maybe the issue is in compile/install-sh? I'm attaching my emerge --info and the post-processed Makefile.
Created attachment 149461 [details] post-configure Makefile
Created attachment 149491 [details] emerge --info (In reply to comment #15) > Maybe the issue is in compile/install-sh? I'm attaching my emerge --info and > the post-processed Makefile. If install-sh is at fault, then let autoconf regenerate that file in src_compile() with autoreconf: src_compile() { autoreconf -f -i --verbose || die "autoreconf failed" CXXFLAGS="${CXXFLAGS} -fno-strict-aliasing" egamesconf || die "configure failed" emake || die "emake failed" } and see if helps. I have both "sandbox" and "strict" in FEATURES too, but get no errors :P The only thing that jumps at me in your emerge --info is that you're using an ~arch portage (2.1.5_rc2) while I'm on stable (2.1.4.4). I'm attaching my own emerge --info in this reply.
I tried your suggestion (though it probably has the same effect as eautoreconf in #13) and it ended in the same failure. Doubtful that Portage versions have anything to do with it as I encountered this issue in 2006. My workaround still allows the package to emerge successfully: ./configure must not define --libdir=/usr/games/lib, which egamesconf automatically does.
OK, last shot before reverting back to your original solution. This: http://devmanual.gentoo.org/ebuild-writing/functions/src_install/index.html mentions: Sometimes this [emake install] will end up installing a few things into strange places. If and only if this is the case, the einstall function can be used: einstall || die "einstall failed" So does replacing: emake DESTDIR="${D}" install || die "Install failed" with: einstall || die "einstall failed" fix this?
Created attachment 149598 [details] frobtads-0.10.ebuild Hi Nikos, I had tried einstall yesterday without success. I'm attaching the ebuild which works for me, has been tested with all use flag combinations on x86.
Created attachment 149608 [details] frobtads-0.10.ebuild Then we'll go with that. (I think eautoreconf isn't needed since it was only a shot at trying to fix your problem.) I also wrote a src_test() for the ebuild (I head Gentoo devs love this one), but I came across a problem with exiting the test when the tads3compiler USE flag isn't there (we need to compile the sample game with t3make, therefore tads3compiler is needed in USE). I'm using "if ! use tads3compiler": src_test() { if ! use tads3compiler; then einfo "Skipping test. Add the tads3compiler USE flag to enable it." return fi # Compiler and runtime tests follow... # ... } However, the function doesn't return when tads3compiler isn't in the USE flags and the test goes on (and fails since t3make isn't there). Any suggestions? I'm attaching the ebuild. I would be glad if someone could tell me why "if ! use tads3compiler" fails to bail out if tads3compiler isn't in USE. Another problem with the test is that only the first line in the here-document has an effect; the rest is ignored: ./frob -i plain -p samples/sample.t3 <<- END_FROB_TEST take all. drop all go north END_FROB_TEST "go north" is totally ignored. Why?
Created attachment 149620 [details] frobtads-0.10.ebuild Slightly updated ebuild. Differences: * Improve the punctuation of DESCRIPTION slightly (most important ;-) ) * Add a "debug" USE-flag to enable the t3debug configure option, and also the TADS3 compiler test suite. * Use RESTRICT to disable the tests when not building the TADS3 compiler, instead of an explicit if (this one's a bit debatable... I find RESTRICT cleaner, but there /might/ be merit in giving the user a message explaining why the tests aren't being run. In any case, the cleanliness of RESTRICT is spoiled a bit by having to use an if anyway, to test for the debug flag). * Use die in a couple more places. * Slightly change the set of doc files installed: remove COMPILERS, since it's just installation instructions, and Gentoo policy is not to install those, and add SRC_GUIDELINES (again, perhaps debatable whether this is useful to ordinary users, but a few other packages do install HACKING files and the like). * Add "go north" to the here doc in src_test, although judging by the output, I seem to be seeing the same issue as you with it not being executed. I have no idea why that is. As for setting CXXFLAGS explicitly versus append-flags, I'd say the latter is cleaner, but I'll do it your way for now. In any case, the /real/ fix would be to find what part of the code doesn't work with strict aliasing, and fix it. ;-) Finally, the sandbox violation: looks like it's coming from the AC_SYS_LONG_FILE_NAMES in configure.ac, the relevant part of configure being > for ac_dir in . "$TMPDIR" /tmp /var/tmp /usr/tmp "$prefix/lib" "$exec_prefix/lib"; do > # Skip $TMPDIR if it is empty or bogus, and skip $exec_prefix/lib > # in the usual case where exec_prefix is '${prefix}'. > case $ac_dir in #( > . | /* | ?:[\\/]*) ;; #( > *) continue;; > esac > test -w "$ac_dir/." || continue # It is less confusing to not echo anything here. > ac_xdir=$ac_dir/cf$$ > (umask 077 && mkdir "$ac_xdir" 2>/dev/null) || continue > ac_tf1=$ac_xdir/conftest9012345 > ac_tf2=$ac_xdir/conftest9012346 > touch "$ac_tf1" 2>/dev/null && test -f "$ac_tf1" && test ! -f "$ac_tf2" || ac_cv_sys_long_file_names=no > rm -f -r "$ac_xdir" 2>/dev/null > test $ac_cv_sys_long_file_names = no && break > done I'm not sure why one of you sees and the other doesn't; the "test -w" suggests that it wouldn't be an issue when building with userpriv enabled, but neither of you has it in emerge --info, so it's probably not that. In any case, it's probably better to fix it rather than hack over it by not using egamesconf; a possible but hackish fix would be to set ac_cv_sys_long_file_names=yes in the environment that configure runs in.
Created attachment 149632 [details] frobtads-0.10.ebuild (In reply to comment #22) > * Add "go north" to the here doc in src_test, although judging by the output, I > seem to be seeing the same issue as you with it not being executed. I have no > idea why that is. The full set of commands I wanted to use includes testing of saving and restoring: take all. drop all. go north save testsave.sav back restore testsave.sav take all But I only left "take all. drop all." in the ebuild since the rest is ignored. I'm putting those all in the ebuild now; hopefully someone will come up with an idea of how to make them work. There's another problem with here-documents in ebuilds I couldn't fix. I posted about it in http://forums.gentoo.org/viewtopic-p-5060465.html#5060465 > Finally, the sandbox violation: looks like it's coming from the > AC_SYS_LONG_FILE_NAMES in configure.ac Thanks for catching it. I'll probably remove this check upstream for 0.11 (it's there to check for Unices with a 14 characters limit in filenames; seems a bit paranoid to check for it these days.) Anyway, in your ebuild you used egamesconf which isn't working correctly right now (at least for Kai). So for the 0.10 ebuild we should use Kai's code, and for the upcoming 0.11 use egamesconf. > In any case, the /real/ fix would be to find what part of the code doesn't > work with strict aliasing, and fix it. > ;-) It looks like the bug is in GCC rather than the code. It seems to happen with GCC 3 (3.1.x) and higher, but all is fine with GCC 4.x 3.0.x and 2.x (and other compilers). In any event, debugging it turned out to be quite impossible (for me) since the produced machine code (and assembly) were not useful at all; this usually is a sign that it's a compiler bug. Two other things: In your ebuild you have: mv t2compiler/* "${S}/t2compiler" I remember reading somewhere in the ebuild docs that one should quote directory vars like this: "${S}"/t2compiler instead of: "${S}/t2compiler" Also, I don't really get the final "cd ${S}" in src_unpack() in many ebuilds. I saw Kai was putting it back in. Is it needed? It doesn't seem to be. I'm attaching a new ebuild with all your additions but using econf instead of egamesconf. I've adapted the description to mention the development tools too; hopefully users will figure out that they need tads{2,3}compiler in USE to enable them though. Don't know if it's a good idea to print a message after the installation to inform them that they need those USE flags to get the compilers. If yes, feel free to update the ebuild (it's about time we have something "final" :P)
(In reply to comment #23) > The full set of commands I wanted to use includes testing of saving and > restoring: > > take all. drop all. > go north > save > testsave.sav > back > restore > testsave.sav > take all > > But I only left "take all. drop all." in the ebuild since the rest is ignored. > I'm putting those all in the ebuild now; hopefully someone will come up with an > idea of how to make them work. Hmm, OK, I'll see if I can figure that out some time. > Anyway, in your ebuild you used egamesconf which isn't working correctly right > now (at least for Kai). So for the 0.10 ebuild we should use Kai's code, and > for the upcoming 0.11 use egamesconf. OK, fair enough. > It looks like the bug is in GCC rather than the code. It seems to happen with > GCC 3 (3.1.x) and higher, but all is fine with GCC 4.x 3.0.x and 2.x (and other > compilers). In any event, debugging it turned out to be quite impossible (for > me) since the produced machine code (and assembly) were not useful at all; this > usually is a sign that it's a compiler bug. OK > I remember reading somewhere in the ebuild docs that one should quote directory > vars like this: > > "${S}"/t2compiler > > instead of: > > "${S}/t2compiler" That's just a style thing, but yes, your version does seem to be more common in ebuilds. > Also, I don't really get the final "cd ${S}" in src_unpack() in many ebuilds. > I saw Kai was putting it back in. Is it needed? It doesn't seem to be. It's not needed as the last statement in a phase function, since the package manager will always set the working directory explicitly before it executes the next phase. It's conventional to use it in src_unpack before applying patches and/or running eautoreconf; whether or not it's necessary depends on how the patch was generated, but usually people do it anyway. > I've adapted the description to mention the development tools too; > hopefully users will figure out that they need tads{2,3}compiler in USE to > enable them though. Don't know if it's a good idea to print a message after > the installation to inform them that they need those USE flags to get the > compilers. If yes, feel free to update the ebuild (it's about time we have > something "final" :P) I'd think the flag names are obvious enough. If someone wants to add the messages, go ahead, but I won't bother.
(In reply to comment #24) > > But I only left "take all. drop all." in the ebuild since the rest is ignored. > > I'm putting those all in the ebuild now; hopefully someone will come up with an > > idea of how to make them work. > > Hmm, OK, I'll see if I can figure that out some time. Oh, I see what's going on... the first command generates a lot of output, so the remaining input lines get eaten by all the "[More]" prompts (although they don't show up, because they get followed by a \r rather than a \n and then overwritten by the following output). There doesn't seem to be an obvious way to disable those; any ideas (other than adding an extra 69 blank lines after the first line of the heredoc, which actually works but is obviously horrible)?
Created attachment 149639 [details] frobtads-0.10.ebuild Gah! I feel quite stupid now :P I've changed the ebuild to only test save and restore (still good for a stability/sanity test). I'll fix the code upstream to not issue more-prompts when input is coming from a pipe. (In fact, I thought I already did this, but it turns out it isn't working.)
Would just comment that running eautoreconf seems to be the rule whenever a package uses Autotools as part of its build system. I'm glad you found the cause of the mkdir bug - spent quite a while trying to diagnose it, and I suspected it was part of configure or make and not make install because of when it occured, but didn't know exactly where to look.
Not sure about autoreconf. If the package was created with a too old or too new version of autotools and is using macros that no longer exist or don't exist yet, autoreconf will fail. And besides, the whole point of the autotools is to not require the end user to have them installed at all; everything is self-contained. I'm bumping this to the new upstream release 0.11. The ebuild now uses egamesconf since the AC_SYS_LONG_FILE_NAMES has been removed; Kai, can you confirm that it works OK now? The more-prompt issue is still there, so no changes to src_test(). Upstream package naming has been changed, so SRC_URI has been changed too. 0.11 is the first non-beta release since 0.7. It's the latest stable version.
Created attachment 149755 [details] frobtads-0.11.ebuild
Yep, thanks Nikos. Tested 0.11 ebuild with various combinations of use flags, works fine.
Version 0.12 has been released. The last 0.11 ebuild works without modifications. Thanks to David Leverton, we now have the "interactive-fiction" overlay (accessible with layman). FrobTADS 0.12 along with many other IF tools are already in there :)
In portage. Thanks for the bug report and ebuild submissions.
