Quote Originally Posted by Gleeok View Post
This is somewhat a conglomeration of different topics.

Sorry guys; I'm a little unsure about the repo status as well. Keep in mind that 'master' is a few years of random commits - this represents the shardstorm repo as well. Most of these are from Saffith and I don't know what he wants to keep and throw away. I know that I want to keep all my changes, though the most I've done with ZC this last year is to basically get it all open sourced, and I'm not too sure about what's going on with it on the source code level: The files between the trunk and 2.50 can vary wildly, and I'm skeptical that this won't introduce really stupid (and potentially nasty) bugs. Testing will be required, and after 2.50.4 I think we should bump the major version.

I think I might feel better about merging files into 'cmake 2.50.x' one at a time. I've never done such a large "code squish" before, and certainly not one with multiple devs that represent both such a large time frame and also with an interestingly complex codebase that users count on to be stable at the same time. My subversion skills are also very basic as well, which I think is normally a good thing not having to lean on tools too much, but not so much here. To put it another way, my git skills are simply terrible.

Instead of CMake I'd prefer to migrate over my custom build from the trunk since it eliminates minutes (over 400% faster) off of the compile times and binary sizes, but I can download CMake and test it anyway.





We definitely will not be accepting any pull requests until everyone gets settled anyway so what's the difference?



[edit]
Downloading now...

1)Okay, so branch 'cmake' is definitely the WIP 2.50.x->master? So that's the one I should start dumping things into, right?

2)Can we just swap that one with master once the minor issues get sorted out, then worry about the rest of it afterward, or does anything else need to be done first?

3)2.50.x should be kept for 2.50.3 and short-term only minor bugfixes then, and we will accept only bugfixes for this branch then; is this also correct?


[edit2]
If we have people maintaining project files for different builds can we just have cmake as a 'backup' for everyone else?


..The holidays are getting to me. I'll have to start this project tomorrow. My brain is turning into mush.
Let's do this: we will make the cmake branch (containing the 2.50.x changes) the master, and then we can look together at the changes you've made to the current master and merge them in one at a time, if they still make sense. Saffith was unhappy with some of the changes in the current master branch, but we can discuss with him and pull out the good bits.

I don't know if you've used CMake before, but it's basically a makefile for makefiles. You hit a button and it generated the MSVC 2010 project file for you, the MSVC 2016 project file for me, the Linux Makefile for Saffith and ZoriaRPG, etc. That way you do not have parallel but different builds set up by different developers for each platform, and you do not have to worry (as much) about one of the builds becoming out of sync with all of the others. If you want to add or remove a .cpp file from ZQuest, for example, you make the change in one place, in the CMakeLists.txt, and it automatically modifies the MSVC 2010 project file, 2016 project file, the Linux Makefile, etc.

CMake also makes it easy for new developers to download the source code and build ZC, as it's an extremely common and standard tool for multi-platform projects.

There should be no problem getting CMake to configure the MSVC project to speed up compilation (presumably, by using precompiled headers?). I will help you with this, once the basic compilation is working.

EDIT: And if you're getting errors, feel free to ping me on Skype (id: evouga) and we can sort them out together. (That also goes for you, Saffith).