Other ways to support Sylphis3D...
Syndicate
Translating to a CMake
Fri, 04/27/2007 - 21:57 — noteventime
Hello,
I'm currently working on trying to "translate" the Visual C++ project file to a CMake file that can be used for building on both Windows, Linux and (maybe) later Mac OS.
I'm just making sure that this, or something similar, isn't already being done by someone else.
Anybody else working on something similar to this (the scons files not counting)? ;-)
Any idea?
http://www.pastebin.ca/461932
Does anyone know what those errors could be referring to. I get them when trying to compile client.cpp. I've tried both -Wall -v -pedantic, none of which gives me any warnings that I associate with this it.
When did you last try to compile sylphis on GNU/Linux? Maybe some kind of weird incompatibility between Microsofts and gccs STL implementation?
Output with -Wall -pedantic: http://www.pastebin.ca/461931
The first error is about a
The first error is about a ";" that is not supposed to be there. I removed it and MSVC++ does not complain... can you see it GCC does not now too?
Still the same
I'm afraid that I still get the same errors after updating from subversion. :-(
Noventime, Thanks very much
Noventime,
Thanks very much for doing all this work in (re)porting to Linux. It'd be great for Sylphis to be cross-platform out of the box. Unfortunately, I can't be of much (any) help in debugging these problems, but I did want to let you know that Harkal'll be back, active on the site in a few days; his Internet connection been gone down. Once he's back, I'm sure he'll have all sorts of problem-fixing ideas. :)
-=Derek
Thank you
Thank you for the encouragement :-)
and thanks for the information, I'll just try to get the other build errors fixed till he's back online. I'm afraid my C(++) skills are a little too limited for the STL problem, but I'll continue trying to get it fixed.
I'm trying to compile it on x86_64 gentoo with gcc 4.1.1, GNU Make 3.81, kernel 2.6.19 using cmake 2.4-patch 5.
If any of the other people working in getting sylphis to compile on *nix have any information on their progress it would be great if you told us/me, no use with multiple people doing exactly the same thing without communicating (In short: I'd rather like to steal some of your work ;-)).
I'm a little busy at the moment, though I think the problem is probably due to including some weird header file before including a STL header. I'll check it out the day after tomorrow, I'm afraid I can't fix it any sooner. (If harkal or someone else is back before that you might want to try to fix it.)
I dont really see a problem
I dont really see a problem with the use of deque<> ... deque is only used to hold the frustum planes (frustum.h). There must be some other kind of problem.
Were you able to compile the hklib ? I can build that on my system. It actualy builds out-of-the-box with the scons script that is provided....
Deque and hklib
I was able to compile hklib with the provided scons scripts, if I can get the CMake script to work I'll add hklib too. The only major problem I have right now is the deque one which I still get from all the files in the list. I've tried compiling them manually, outside CMake, directly with g++, and got the same errors.
The only explanation i can come up with is that some custom header is included before deque.
Can you send me a patch with
Can you send me a patch with your CMake changes...?
No major changes
I've not done any major changes to the code (nothing you can't fix in a minute). The reason I don't want to create a patch is that I'm not sure if I've changed something I shouldn't have changed while trying to fix the deque problem.
I can send you the CMake build script if you want, is there some way i can post it here?
By the way, which
By the way, which distribution are you trying to compile on? Not, of course, that it should matter, but just for the sake of... for the sake of it.
Files
If it's any help, i get the error when trying to compile these files. I've unsuccessfully been trying to fix this error.
Something must be making the STL deque container go mad, sadly C(++)s irritating #include is making it impossible to trace... Any ideas?
core/src/client.cpp
core/src/engine.cpp
core/src/main.cpp
core/src/material.cpp
core/src/materialparser.cpp
core/src/md3model.cpp
core/src/meshloader3ds.cpp
core/src/modelmanager.cpp
core/src/particlesystem.cpp
core/src/renderable.cpp
core/src/renderablemultimesh.cpp
core/src/renderer.cpp
core/src/rendererARB2.cpp
core/src/renderingview.cpp
core/src/scenemanager.cpp
core/src/scenemodel.cpp
core/src/smfmodel.cpp
core/src/texturefont.cpp
core/src/python/sylphis_wrap.cpp
core/src/cmapscene/cmapscene.cpp
core/src/sound/soundenv.cpp
Found it!
I think I've been able to locate the problem. GCCs STL doesn't like the redefinition of min/max (in imagefile.h).
I'm going to see if the error can be fixed by defining min and max locally just where they are needed and then undefined again or if we'll need to find another solution.
Sorry for taking some time, I've been rather busy the last three days.
>Sorry for taking some
>Sorry for taking some time...
You've been re-porting Sylphis to Linux --volunteer! Take as much time as you need. :D
I'm actually pretty excited about this on a personal level, because I'm trying to switch from XP to Linux for as much as I can. This'll be Just one more thing not to have to boot into Windows for. ;)
Thanks again!
-=Derek
Not dead
Hiya!
I think (read hope) that I've almost fixed it now, the rest of the errors were a lot less cryptic and I had some spare time now. I've got one nasty template error, probably simple to fix but the vastness of the error message scared me away, a few conversion errors and errors in the SWiG generated file, which worries me a little, hopefully they'll be fixable though.
Kudos to harkal (and d.mounce?) for keeping the code cross platform. :-) Otherwise this would be a _LOT_ more work.
That's all for now, going to bed.
Excellent!
Glad you're making progress! I keep getting more and more excited about being able to run Sylphis in Linux --even if Quark has to be run under Wine.
>Kudos to harkal (and d.mounce?)
NO! Lol. All the credit --all of it- goes to Harkal. I only licensed Sylphis .92 (when it was still commercial) a year ago, and wrote a few posts in a blog about using it. Long live the great Harkal! :D
Righty, enough there now. Again, thanks for all your help! (By the way, especially if you ask Harkal about it, I never stop saying thanks...)
-=Derek
Conversion
I don't know if you remember the code harkal, but in a number of the rigid* files (rigidbox e.t.c.) you convert dspaceids into int, which GCC won't allow. I've tried reinterpret_cast but the dxspace struct is only predefined in the headers... Any ideas? How does this work in Visual C++?
Use a standar C static cast,
Use a standar C static cast, to make the compiler stop whining!
Sorry for taking so long to answer.
It's not accepting a C-style cast either.
It works if I cast it to a S32* and then dereference it, so I'll try that :-).
Another major problem I'm
Another major problem I'm too stupid too fix.
"i->second.erase(j)" that piece of code is located on line 251 in scenemanager.cpp. GCC doesn't like this at all and gives me this template error: http://pastebin.thecodebit.net/106 .
At least one of the reasons being that map::erase doesn't return anything in the standard STL (only in the MSVC++ one). I'm not totally sure what you're doing here but a similar error is on line 258.
I'd be nice if you either tell me some about the code or maybe even rewrite it so it doesn't rely on map::erase returning anything.
STL map::erase() returns an
STL map::erase() returns an iterator in the latest draft... anyway changed it so it does not use the return value....
Thanks! :-)
Thanks! :-)
Almost got it to compile and
Almost got it to compile and link... Any idea if these things are written by you or if I'm using the wrong version of ODE? http://pastebin.thecodebit.net/109
I wonder if those precision errors were due to me compiling on a 64bit host... I'll have a look at it when I'm done with compiling/linking Sylphis.
I never tried sylphis to
I never tried sylphis to compile at 64bits... I'm sure there will be issues... I suggest you start posting patches so other people (and me) can help in a more productive manner!
I doubt it'll help, but
I doubt it'll help, but there's a patch on SF now. The CMake file still doesn't run SWiG, but I've begun working on it.
Sorry for the big delay... I
Sorry for the big delay... I was just to busy the last days... I just downloaded your patch... it doesn't contain any cmake files! Can you send that too?
No worry, I think I'm just
No worry, I think I'm just as much the cause of delay as you are.
I thought I'd added the cmake file, strange...
I'll just attach the cmake file directly (or would you rather like an updated patch?).
Just the CMake file will do!
Just the CMake file will do!
I also moved your patch to
I also moved your patch to the official bug tracking system :
http://mantis.sylphis3d.com/view.php?id=5
Check it out...
Sylphis3D uses a modified
Sylphis3D uses a modified version of ode. Use this patch http://devnet.sylphis3d.com/downloads/ode_sylphis.diff against the latest svn version... hope it helps...
Thanks, I'll try it out.
Thanks, I'll try it out.
Patch
The patch file isn't the easiest to read, any summary of what the patch changes? And what version did you apply it to?
Got a lot more free time now. Hopefully I'll get something done for once :-).
Nevermind, works with 0.8
Nevermind, works with 0.8 (compiling anyway).
Linking to the new lib fixed all the missing ODE things. I had some trouble compiling it due to your patch adding a class. For some reason it compiled the header as a C-file. This was fixes by simply making the class a struct, might want fix that in the patch.
Welcome back :) The patch is
Welcome back :) The patch is against the latest ode tree that resides in the svn. But probably will work with 0.8 also. The struct solution does the trick! Good!
Going to fix the hackiest
Going to fix the hackiest parts before anything else :-P.
What was your reason for redefining the built-in random function in gutil.h?
Was there any reason for including windows.h in debugdrawing.h
Actually I'm defining a
Actually I'm defining a random() function. There is no random in the C/C++ stdlibs...
The windows.h will have to be shielded in ifdefs for windows only. Its required for gl.h.
That's strange. GCC warns me
That's strange. GCC warns me about it being redefined... I'll just make sure it's only compiled for non-GCC compilers.
Success
It's compiled!
I'm getting this error when trying to run it though:
"Unhandled exception :
Failed to import python importer"
I read about this in some other thread, is it because I compiled sylphis with stackless2.5?
Hmmm.... no
Tried with 2.4.3, which didn't help at all.
So cool!! Very good!! The
So cool!! Very good!! The problem with the "importer" is a runtime error... caused by incorrectly setup runtime environment. This is going to to happen until the runtime is proper. The major problem is that the environment that comes from the SVN of Sylphis3D contains only windows versions of python stdlibs. There are modules there are writen in C and are compiled in .so files. You should be seeing a more elaborate exception on the console. If not try redirecting the stderr to a file... the exception description should provide info on what module is missing from the stdlib directory...
noteventime can you post the
noteventime can you post the patch at mantis?
Sure, I was hoping to be
Sure, I was hoping to be able to test if it actually ran on Linux (not just compiled) before I posted the patch. I'll just post it anyway. I'll also post some kind of dirty list of the things I've changed (or rather the ones I remembered to log).
We should follow the open
We should follow the open source commandment "Release early... release often..." :) I will look into the patch first thing after I boot linux....
Since I'm dummy with
Since I'm dummy with cmake... can you tell me where does it expect stackless tree to be installed? Or how do I provide the path?
ccmake
You provide the path with the ccmake configuration utility. Simply run "cmake ." first, then run "ccmake ." and there should be two values for the python paths (library and includes).
I already found something I forgot to fix. CMake expects the patched ODE headers to be in a folder called ode/include in the same directory as the CMakeLists file. I'll fix that as soon as I have something more to fix. For now just do a link ("mkdir ode" + "ln -s extern/include/ode/ ode/include/") to the headers you provided in the last revision.
Very good!!! I acknowledge
Very good!!! I acknowledge the compilation!!! Very good job!!
However I thing we have a long way to actually running on linux... so lets begin !! :)
Congratulations!
And a huge honking thanks! (Truly, a honking one) :D
It's absolutely great that I'll not have to boot into Windows anymore to use Sylphis.
I'm pretty sure the "Failed to import python importer" error was fixed in a recent commit. (The fix is there in rev11 for sure.) When did you last update from SVN?
If that doesn't fix it, then perhaps make sure Python is in the PATH and whichever other places it needs to be; when I had the importer issue on Windows it was because Python was either not installed, or not registered with the system.
-=Derek