Building on Mac and Linux

[DarkDragon]

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).

[DarkDragon]

Mates, IDK what is happening. When Saffith said he wanted to make 2.50.x 'master', because he wanted to toss out the refactoring, and Gleeok said that'd be fine, we've all been acting under the presumption that this was finalized. That's why you can't let weeks pass when deciding these things, and then jump in and change things without public discussion and announcements of the plan.

We've all spent considerable time working on this mess, and remerging the changes is a genuine pain.

Make something main that isn't going to change. I suggest 2.50.x, stable. Make something the next dev branch. Set them in the repo, and we'll work from there, but please stop changing the plan, and doing things without discussing them in threads; so that we're all on the same page.

I'm going to again ask that the stable version slated as the next release is kept as master. That way, it's sane, and anyone who wants to build from it knows what is what. Making the development branch 'main' is just downright confusing to everyone, and it's very rarely done that way.

We can probably fix our changes in one or two days, but it's still a waste of time.

Easy there. You can't complain simultaneously about 1) lack of decisive action and 2) lack of extended discussion. The discussion is happening right here and the plan is being made right here. Once Gleeok and Saffith and I are on the same page, you will have your reorganized repository. The repository has been in its current state for almost a year, another week or so won't hurt, especially (as you yourself point out) there needs to be public discussion before wildly rearranging things around. Patientez.

Also, is the CMake branch going to retain the MinGW/MSYS essentials? I don't particularly want to shift to CMake, especially as the way I've things configured now, it takes me all of two seconds to shift lib stuff out, and I can do simultaneous builds using the old, and the new libs without changing any paths or includes. I could use separate makefiles, I suppose, but this way I only need to decide if I use MSYS or cmd.exe to do the build. (MSYS builds on the old libs, cmd.exe with MinGW32-make does ag4.4.)

It will, if you help me configure it
As for switching to CMake, any alternative that is platform-specific (and a single *nix-style Makefile is exactly that) is a non-starter. I'm 95% confident that CMake can configure your Makefile to do whatever it is you want to do, i.e. support two different versions of Allegro (though I'm hoping that in short order we will all simply switch to 4.4, assuming that solves more problems than it introduces). Yes, switching to CMake is a slight pain, but in the words of Spock, "the needs of the many..."

[Gleeok]

@ZoriaRPG - ZC has always had the current dev branch as main in the past; we're just used it I guess. For everyone else bitching about it during the holiday season remember that it's the holidays. Please stop bitching about it. Just swapping A<-->B around in the repo doesn't do anything. It needs some elbow grease as well. Thank you come again.

@DarkDragon : The reason I never use cmake is because it never works right. It's always complained about missing files or whatever else. I'll give it a go, though I don't mind maintaining a project file.

[DarkDragon]

@ZoriaRPG - ZC has always had the current dev branch as main in the past; we're just used it I guess. For everyone else bitching about it during the holiday season remember that it's the holidays. Please stop bitching about it. Just swapping A<-->B around in the repo doesn't do anything. It needs some elbow grease as well. Thank you come again.

Yes, exactly.

@DarkDragon : The reason I never use cmake is because it never works right. It's always complained about missing files or whatever else. I'll give it a go, though I don't mind maintaining a project file.

It can be tricky to configure the CMakeLists file at first but I will help get it to work. Let me know what errors it gives you

[Gleeok]

This is going well: "#error platform not supported"

Haven't even got to run cmake yet.

[DarkDragon]

What did you run that gave this error?

You should run CMake before doing anything else. Download from https://cmake.org/download/ and run the GUI. It will ask for a folder containing the source, and a folder where to put the build files. Select the root folder for the former and ./build for the latter. Then hit "generate." If there are no errors, it should create for you a Visual Studio project file that you can open inside of ./build.

[Gleeok]

CMAKE is still downloading. :x ..My internet is crap today for some reason...

In the meantime, ZC compiles fine with only a few minor things to fix up.
Now on to ZQuest. (Being able to compile ZC without cmake is also a good idea I think, so I'm doing that as well then build with cmake as well.)

[DarkDragon]

What's the point?

You use CMake once, to generate the project file. It creates a project file that will work on your system, with your MSVC compiler. Then you use MSVC to edit the source/build the code.

You could keep a random second MSVC project lying around, but that is just begging for your build to become out of sync with the repository once somebody adds new files or changes settings (like external libraries) without any benefit...

[Gleeok]

With CMAKE: Every file gives this error: fatal error C1083: Cannot open include file: 'stdint.h':

If I add it to a path I get many more errors... This was the same problem with boost. I forgot how I fixed it.... I'll need to check the log.


[edit] Aha! The problem is that allegro already defines these (in a bad way). ....crap.

[DarkDragon]

You have MSVC 2008, right? I think I know the problem. Can you try re-generating the project and rebuilding using the latest commit?