Hi nido,
Could you test the boost patch in my last post? Whilst I was careful changing it, this actually changes the way configuration works and thus might give unintended sideeffects on the win32 and mingw platforms (are these actually considered different platforms? or is mingw also considered win32?)
Ok, I will. Yet, I do think your patch will have no effect on windows since I'm using MSVC to compile. (Thus, no, MingW and win32 aren't the same thing. As I'm sure you already know, MingW is a compiler, Win32 an OS). But anyway, I'll make the test.
In my humble opinion, working with changed CMakeList.txt can be a problem. If you aren't touching the build system at all these problems may be mitigated. Possibly though some of your changes should be given as command line arguments rather then changes in said file (for example, on my fedora system I need to teach cmake where to find the homemade cegui installation, since i got it installed in a nonstandard path). Regardles of that, it could be argued that such changes may be included in order to have CMake work "by default" on "most developers' platforms". In that regard, I would be happy to help diagnose the trouble you are having.
Unfortunately, the changes I made in my version of the CMakeLists.txt file weren't made out of laziness or fanciness. In short, here is what I mainly changed:
https://github.com/Bertram25/OpenDungeo ... 00fa95f011- I put the project() statement early so that certain cmake variables would be set before their actual use.
- I changed this to that:
- {l Code}: {l Select All Code}
- if(${OGRE_PLUGIN_DIR_REL} STREQUAL NOTFOUND)
+ if("${OGRE_PLUGIN_DIR_REL}" STREQUAL NOTFOUND)
since it was triggering a cmake error on Debian for me. (Btw, I do compile the game on both OS).
Why did I kept those to myself? Well, because it broke the CMake invocation for Paul, and because we both have much more to tackle on with this project, atm. So we decided to look at that later.
(The code needs a hell lot of cleanup and fixes.)
But now you're on it, I guess the time has come to look at the problem and find a common working solution. Please note that I did that as well:
https://github.com/Bertram25/OpenDungeo ... 8c9e163934^ This commit should be changed to make cmake copy any .level files instead of testing for Test.level file only, the Test.level in the level_git/ folder should be copied in the SVN levels/ and the level_git/ folder tossed.
https://github.com/Bertram25/OpenDungeo ... 705df0abd6^ I guess we had a similar idea here.
About the AS question:
I guess nobody is really in charge of code lead anymore, and I understand why Paul felt alone in coding here, but I'd say this, out of pure logical thinking:
Cons:
- The Angel Scripting version bundled in the repo, as you said, is starting to be old.
- It could be put as an outer dependency.
- It might be cluttering only and we might want something we're more at ease with.
Pros:
- AS is fitting for game scripting, as it is used, for instance in Overgrowth, for one.
- The bindings are there, and ready to be completed.
- Some example of porting is actually done. The console command porting is IMHO not the best area to use AS, but we can use that to get inspiration for other use.
- The AS version bundled was made sure of being compilable both on Windows and Linux, at least to me. Several projects do import deps code when using sensible dependencies, so I understand the move here.
Considering this is a spare-time project, we should avoid technology-switch if we aren't completely sure of it. So, either:
- Several coders involved should be at ease with working on the replacement (this means you, Paul and me, atm ;])
- Or we keep it as is for now and concentrate on fixing all the other area, and take the opportunity to ask everyone involved about this in between.
As for me, and as you suggested, I'd open a new thread and use it to vote on what to do.
What do you think about it?
I'll see if i can make a new local branch with changes like that (already have the earlier patch committed
Note that in git, you can squash (merge) several commits into one using interactive rebasing in your local repository. (See git rebase -i)
If you can get at ease with that, you'll be able to do almost anything using git.
(Note also that once you've modified your local clone, you'll have git push -f to force the push to the remote repository if some were already pushed.)
I was wondering about the procedures regarding committing code. Does a ratified process that should be followed before code is committed to the development branch exist? Whilst most code _should_ be compatible between systems without issue there are sometimes cases when system specific subsystems need to be used. Assuming 'development' is the main working branch, do we have a place for "works on x, please test on y" kinda commits (e.g. my boost recognition changes)?
Atm, Paul and me have created <nickname>-integration branches on the sf remote repository where we put experimental stuff we then can cherry-pick from one another to test.
I've also made a github clone, that I use as my own pre-integration branch because github offers much more convenient views and tools to do reviews, etc.
So, I'd say, ask for sf access to Paul, and then push new stuff to a 'nido-integration' branch, so we can make reviews of one another's code before putting that to the development branch.
In a near future, I'd like to sync the master branch and drop the development one because there are already too many branches there
, and because it's more generally the usual way of doing things with git. Little by little, we'll try to get rid of obsolete branches to get stuff cleaner.
I'm also pushing a bit to get the media files (not the media-source that can stay in SVN) into git as certain commits involve synced game files and code, and it would be more convenient, would both file types be in the same repo, allowing new coders and users to clone only one repo before playing. (That's why I made the github clone at first.)
Best regards,
. 
