Bugzilla Bug 149764

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 an attachment (id=98543) [details]
frobtads-0.6.ebuild

Created an attachment (id=98544) [details]
TADS3 (license)

Created an attachment (id=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 an attachment (id=149420) [details]
frobtads-0.10.ebuild

Created an attachment (id=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 an attachment (id=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 an attachment (id=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 an attachment (id=149461) [details]
post-configure Makefile

Created an attachment (id=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 an attachment (id=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 an attachment (id=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 an attachment (id=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 an attachment (id=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 an attachment (id=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 an attachment (id=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.