Bugzilla Bug 188214

Hello, i've made an ebuild for EDGE, a free DOOM Engine, aimed at the Total
Conversion developer, but still able to play the original DOOM games.

This engine has several interesting features:

- Enhanced graphic (through OpenGL)
- Extrafloors (3D floors)
- DDF (Doom Definition Files)
- Jumping, Looking up/down, Flying (JetPack), Zooming.
- Many limits and bugs from original DOOM removed

See the homepage projects for more details.

The latest version is 1.29

Feel free to improve this ebuild (building process through scons is quite
difficult to customize :PPP).

Created an attachment (id=127344) [details]
edge-1.29.ebuild

Ebuild for games-fps/edge-1.29

Created an attachment (id=127346) [details]
SConstruct_fltk.patch

Needed patch for 1.29 ebuild

deps could be simplified like RDEPEND="..." DEPEND="${RDEPEND} dev-util/scons"

no need to call games_pkg_setup because "inherit games" is enough

games_pkg_postinst should be calling in pkg_postinst

$S and $FILESDIR should be quoted too

try env.SConsignFile() to get rid of the sandbox violations

$MAKEOPTS won't work properly with scons (some people use args other than -j)

duplicating games-util/glbsp is no good. you might be able to use
/usr/lib/libglbsp.a

Created an attachment (id=127367) [details]
edge-1.29.ebuild

Thanks a lot for the hints :)

Here's the updated ebuild that includes all your suggested fixed, excluded the
one regarding glbsp: unfortunately it seems to be a bit hard for me at the
moment, i'll try to contact upstream for some help :)

Created an attachment (id=127369) [details]
SConstruct_fixes.patch

Updated patch for 1.29 ebuild

Created an attachment (id=127377) [details]
edge-1.29.ebuild

Oooopppsss.... there was an error in games_make_wrapper line: fixed (now the
ebuild works fine, i promise! :P)

Created an attachment (id=129392) [details]
edge-1.29.ebuild

Added complete dependency from glbsp-2.24 (see bug #188153), glbsp sources
provided by edge tarball aren't used anymore.

Created an attachment (id=129393) [details]
1.29_fltk-glbsp_fixes.patch

Updated patch for improved edge-1.29 ebuild

Created an attachment (id=129444) [details]
edge-1.29.ebuild

Fixed wrong glbsp dependency

Created an attachment (id=136450) [details]
edge-1.29.ebuild

Splitted installation of WAD data files in games-fps/edge-data (see bug
#199710)

Created an attachment (id=136451) [details]
edge-9999.ebuild

SVN live ebuild for EDGE (currently near to 1.31 release)

Created an attachment (id=136452) [details]
SConstruct_fixes.patch

Updated patch for SVN live ebuild

Doesn't build. Using the ebuild or just the sources results in a hole bunch of
lua related errors like so
" src/libedge1.a(l_lua.o): In function `PL_main_ammo':
/var/tmp/portage/games-fps/edge-9999/work/edge-9999/src/l_lua.cc:1206:
undefined reference to `lua_pushinteger(lua_State*, long)' "
I was trying to get the source compiled and was having problems with ftlk. This
is how I found your nice ebuild. I'm guessing that this is gentoo-related
somehow.
Lua IS installed, both globally via portage, and I've also tried adding it to
edge's source folder.
I'm using ~amd64.

Ok, the trick is that lua needs to be built with g++ not gcc.
change "CC= gcc" to "CC=g++" in "edge/linux_lib/lua-5.1.3/src/Makefile"
Obviously you'll need to add a local copy of the lua sources.

Ok, i've opened a bug regarding LUA vs gcc/g++ ;)

Created an attachment (id=162820) [details]
edge-9999.ebuild

Updated ebuild, current SVN sources need edge.wad version 5.8

I'm not quite getting the problem you have with lua. On one side it seems that
you're using an internal copy of lua (which is BAD), on the other side you're
requesting lua to be built with g++.

But i don't know why. Please respond to solars question in bug #234622. Maybe
talk to upstream or someone knowledgable if you can't figure out why this
linking error occurs, b/c forcing g++ on all lua users is a bad idea[tm]

The Problem here is, that edge needs lua to be built with g++ not gcc.
I don't know 'why'...
I also don't think that edge should depend on the global lua build.
Why not distribute(pull it in via the ebuild, patch it so it compiles with g++)
it with edge, thus going around this hole problem!?

In gentoo there is a general dislike of libraries distributed with packages.
The reason is that if there's fix in say lua, often the library in the package
stays the same, opening a potential security hole.

So i'll try to investigate, maybe i can find out why this linking error
happens.

Umm, well this ebuild pulls the latest codebase off the project's svn repo!?
So why can't it also just pull the latest(or even better, the version
required/used by the edge devs) from the lua guys?
Or it could just copy the 'official' gentoo lua ebuild into its tree, patch it
to be compiled with g++, and be done with it!

I don't really see the problem, of course, having edge work with just a
?standard? gcc compiled lua would also be something worth looking into, as it
would save some trouble...

It seems to 'just work' with a standard lua too.
At least it runs.
But edge 1.31 needs a little fix mentioned on the forums:
#include <algorithm>
in src/p_plane.cc

Do you mean it compiles with lua built with c, when applying the
'src/p_plane.cc
'-fix?.
Cause that would be weird...I needed the fix in order to build edge, using a
g++ compiled lua.

No, I mean it build fine using that fix
and one more thing, that I mentioned in bug 234622.

Ok, I can confirm. It builds and runs fine with both fixes.
The '<algorithm>-fix' is already in svn. All we need is the 'extern-fix' also
added... 

According to ajapted, main edge developer:
"When Lua is not compiled as C++, it uses the C setjmp/longjmp functions to
handle errors (lua_error).

Those C functions are bad in C++ because they are not guaranteed to call
destructors of local objects (objects on the stack), and they will bypass any
C++ try/catch block that was active at the time.

Hence for a C++ program, compiling Lua with C++ is a lot better because it will
use C++'s normal exception handling to handle errors instead of setjmp/longjmp"

Just curious, what does Lua upstream suggest in these cases
(meaning when you build it with gcc, but want to link it to
a project that uses C++ exceptions) ?

I looked around a bit and found this faq list:
http://lua-users.org/wiki/BuildingLua

From the first item "Note on embedding Lua in C++ applications":
"If lua was compiled as a C library, which is typical with pre-packaged
binaries, in order to embed Lua in a C++ application (i.e. link C to C++) you
will have to place extern "C" around the inclusion of the Lua headers in your
C++ application".

It goes on to say that upstream recommends building with incorperated source
instead of external libs to avoid this. But i'm afraid this is isn't compatible
with policy in gentoo.

So patching the edge source to use "extern C" around the lua includes while
sticking with USE="-cxx" seems the best bet when you have other applications
around that require lua built with C.

But:
"...because they are not guaranteed to call
destructors of local objects (objects on the stack), and they will bypass any
C++ try/catch block that was active at the time."

This could mean that we 'may' see some breakage due to patching, although it
seems to run fine when built that way.

I still don't get it why its against gentoo policy to pull in a copy of the lua
sources,  and build them with g++.

Ajapted, main edge developer:
"I have made a decision on this issue, and I will update the EDGE code to use a
C-compiled Lua library.

Can't say when I'll get around to it, I'm busy with Uni study for the next five
weeks, so probably after that."

So I guess we wait, issue resolved. Hooray! 

(In reply to comment #28)
> "...because they are not guaranteed to call
> destructors of local objects (objects on the stack), and they will bypass any
> C++ try/catch block that was active at the time."

There are different solutions for this problem, google revealed too many
discussions of this issue, but take a look at the following discussion, for
example:

http://thread.gmane.org/gmane.comp.lang.lua.general/42441

or this one: http://www.lua.org/notes/ltn005.html

So there are ways to do that without building lua with C++. Lua is C library
and if you really need to build it with C++ use bundled library and statically
link with that. Or use dev-lang/toluapp.