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 attachment 127344 [details] edge-1.29.ebuild Ebuild for games-fps/edge-1.29
Created attachment 127346 [details, diff] 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 attachment 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 attachment 127369 [details, diff] SConstruct_fixes.patch Updated patch for 1.29 ebuild
Created attachment 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 attachment 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 attachment 129393 [details, diff] 1.29_fltk-glbsp_fixes.patch Updated patch for improved edge-1.29 ebuild
Created attachment 129444 [details] edge-1.29.ebuild Fixed wrong glbsp dependency
Created attachment 136450 [details] edge-1.29.ebuild Splitted installation of WAD data files in games-fps/edge-data (see bug #199710)
Created attachment 136451 [details] edge-9999.ebuild SVN live ebuild for EDGE (currently near to 1.31 release)
Created attachment 136452 [details, diff] 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 attachment 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.
