Page 5 of 5

Re: Clean up

PostPosted: 01 Aug 2011, 21:29
by svenskmand
Cool :)

Re: Clean up

PostPosted: 07 Aug 2011, 10:37
by StefanP.MUC
By the way, is there a specific reason for this overly complex Boost set up code in our cmake lists? According to the cmake docs (http://www.cmake.org/cmake/help/cmake-2 ... :FindBoost) most of the things our cmake code does is overwriting the default settings of the find module with the default values again. The code also looks like it is at some places inconsistent with the conditionals (MINGW, MSVC, WIN32. The BORLAND compiler, that seems to behave like MSVC, isn't considered at all).

Re: Clean up

PostPosted: 07 Aug 2011, 11:40
by svenskmand
There is something wrong either in cmake or in our cmakelist (probably the last) as both oln and I had to run
{l Code}: {l Select All Code}
cmake -G "MinGW Makefiles" ..
cmake ..

to make the configuring work, if we just run
{l Code}: {l Select All Code}
cmake -G "MinGW Makefiles" ..

as has worked before, then cmake could not find OIS inside of Ogre :S

Re: Clean up

PostPosted: 07 Aug 2011, 11:45
by oln
StefanP.MUC {l Wrote}:By the way, is there a specific reason for this overly complex Boost set up code in our cmake lists? According to the cmake docs (http://www.cmake.org/cmake/help/cmake-2 ... :FindBoost) most of the things our cmake code does is overwriting the default settings of the find module with the default values again. The code also looks like it is at some places inconsistent with the conditionals (MINGW, MSVC, WIN32. The BORLAND compiler, that seems to behave like MSVC, isn't considered at all).

The boost stuff is to find the boost libraries that comes with the Ogre SDK on windows. Otherwise the script won't look there. (Though there were some lines that could have been enclosed in a if(msvc) block.) Also, we might want to let it use a system boost installation if it exists.
By inconsitensies, are you referring to the compiler flags block? That was the one thing I didn't really clean up last time I went through the file, but is something that should be done.

The Borland/Embarcadero environments aren't used a lot these days, at least not for FOSS or hobby development. Using them would also requiring compiling all dependencies from source, if they even compile. C++ builder is not free of charge either, so it's rather hard to test it. If somone wants to add support for this, they are free to do so, but I don't think it's worth putting any effort into it. (I would think that supporting xcode and possibly icc would be prioritised before this if we end up adding supporting more compilers/systems in the future.)

EDIT:
Adding to what svenskmand mentioned, happens with mingw, not on linux. Not sure about visual studio

Re: Clean up

PostPosted: 07 Aug 2011, 12:03
by StefanP.MUC
Yes, I also have some minor issues. Maybe the AngelScript linking still doesn't work as expected and causes some conflicts...

I have these problem:
- I use Eclipse + MingW and for some reason does Eclipse fail to resolve some include paths (compiling works, however, so they are set correctly). So this could actually be a problem by cmake itself (wrongly generated Eclipse project files)
- I always get a "libOpenDungeons.dll.a" (only 6 KB) build, but I don't know where this command is given
- sometimes Eclipse has some conflicts with the AS subproject in its workspace

Solutions I can think of:
- I could try to switch back to the manual including AngelScript to see if this solves our problems (but this is not good practice).
- build AS manually and then link to it, without us providing the libs. (This would need adjusting the build tutorials on the wiki, makes it harder for newcomers).
- steamroller tactic: write a new cmakelists from scratch instead of continously messing with the old one that is IMHO still very messy, even after the partial clean up (especially the lower parts, starting with boost).

Re: Clean up

PostPosted: 07 Aug 2011, 12:07
by oln
StefanP.MUC {l Wrote}:- I always get a "libOpenDungeons.dll.a" (only 6 KB) build, but I don't know where this command is given

I suppose this might be for linking with the angelscript target.

Re: Clean up

PostPosted: 08 Aug 2011, 10:00
by StefanP.MUC
Yes, seems to come from AngelScript. But why isn't something like this generated for pthreads?

I just pushed a commit to our cmakelists: I removed the add_subdirectory call, and only added Angelscripts /lib dir to the link_directories. So, now everyone has to compile AS manually before compiling OD (only on the first compile or after new releases of AngelScript, of course).

I still have some issues with Eclipse that seem to be caused because AS is in the same directory structure (but fewer issues than before the commit)...

Can you check if this also maybe fixes the OIS finding (I never had problems with that, btw, that's the only thing that always worked for me from the beginning while building OD :D)?

With all this problems that AS compiling/linking causes, I more and more come to the opinion that we maybe really should only tell the people to download AS themselves, compile it and put the lib into the OD folder. I don't really like it this way, however, because it makes it harder for new people to get the game compiled, but seeing all the problems that the "direct inclusion" into our codebase is causing....

Re: Clean up

PostPosted: 08 Aug 2011, 12:55
by svenskmand
If you do not want AS in the GIT repo anyway then lets make a Ubuntu package for the lib. Although I am not sure that would be useful for others since on the AS homepage they have this comment
The library is not distributed in binary form, because most developers prefer to link statically and usually need to control the settings used when compiling the library. See the manual for more information on how to compile the library.

Why not just compile it when we compile OD as we do right now? I do not see why this should not work.

Re: Clean up

PostPosted: 08 Aug 2011, 17:06
by StefanP.MUC
Because it seems that this is causing some problems with some cmake generators. At least the Eclipse project file generated by cmake doesn't handle it properly if we call the AS cmakelists from our cmakelists.

Re: Clean up

PostPosted: 08 Aug 2011, 18:54
by svenskmand
Then what if you merge the two cmake lists instead of refering to one in the other?

Re: Clean up

PostPosted: 08 Aug 2011, 19:54
by StefanP.MUC
That's what I did in the beginning. Problem there is that we would have to maintain it ourselves, even if there's an "official" one coming with Angelscript. However, this should be the most easy method for newcomers and the least error prone method (as it seems after trying all the different possibilities).

Re: Clean up

PostPosted: 08 Aug 2011, 20:12
by svenskmand
If you just document how to merge the two cmakelists in a readme in the repo then I guess it should be fine. That is how I did it with the Windows installer and the Ubuntu packages.

Re: Clean up

PostPosted: 08 Aug 2011, 20:16
by StefanP.MUC
There's not much to document, the only thing to do is to extend the .cpp file list in the cmake file by the cpp files from Angelscript.

I'll try some more things tomorow about these issues.

Re: Clean up

PostPosted: 08 Aug 2011, 20:21
by svenskmand
Well if it is not obvious then write it in a readme in the repo so others know what to do if your not around to do it if/when we need the new AS source included.

Re: Clean up

PostPosted: 09 Aug 2011, 19:55
by StefanP.MUC
Just pushed a commit about cmake. I reverted it back to directly built the sources into our binary. Then I'd also updated some Find modules for cmake (Ogre, OIS, ...) from the latest Ogre repository.

Can you check if cmake now works again like intended? Especially the OIS finding.

After doing this and cleaning up my folders, env variables and caches, cmake works perfectly fine for me now again. Sadly Eclipse still gives me the overlapping error (that nobody else seems to have according to google :D), but it also works perfectly fine again, however. (Maybe really an error in the cmake generator, the erro only started to pop up since cmake 2.8.5)

Re: Clean up

PostPosted: 09 Aug 2011, 20:52
by StefanP.MUC
By the way, since recently OD always wants the debug dll's when I start it. Where can I change this behavior so that it uses the release dll's? I don't think that came from one of my commits (at least I never changed something like this).

Re: Clean up

PostPosted: 09 Aug 2011, 22:25
by svenskmand
It compiles again without any errors from cmake, although when I run the game it gives me the following error :S

Re: Clean up

PostPosted: 10 Aug 2011, 14:45
by StefanP.MUC
Yeah, that's what I meant. For some reason OD wants the debug DLLs (they have a "_d" at the end of their name) instead of the release DLLs from our dependencies (mainly Ogre). I have no clue why this is and where to look for fixing it.

edit: Seems that some of the problems could be from having the cmakelists file not in /src anymore (cmake then automatically seems to declare the thing as an "out-of-source build", [cmake FAQ]).
Maybe we should also rethink our whole directory structure (e.g. I never liked it to have /src and /include separated). This would also allow to have some much cleaner separation between actual OD stuff (our sourcecode with includes), dependencies (AS, dirent.h, tinygettext ...) and other stuff, and the cmake files would go into the source folder. This way we could also start using zip files for ogre when we are at directory refactoring anyways.

Re: Clean up

PostPosted: 10 Aug 2011, 23:30
by oln
The reason why it asks for debug dlls is because I added some things, as I was debugging something and using the debug version of ogre. If built in release mode it should be using the release dlls, so either something in the cmake-script is wrong, or there is something wrong with the code which decides what plugins.cfg file to use. An easy workaround is to edit the plugins_d.cfg file untill this is fixed.

Re: Clean up

PostPosted: 12 Aug 2011, 15:54
by oln
I think I have fixed this issue in the latest commit.

Re: [DONE] Clean up

PostPosted: 15 Aug 2011, 11:06
by StefanP.MUC
Just marked this thread as [DONE] and emptied the list in the first post. Thread can be closed (I have no moderator rights). For further clean up tasks and/or questions use the other one or start a new one.