Build with Cmake

[mokou]

Step 1 for supporting alternative compilers.

[nmlgc]

This has gone on long enough by now, and I don't want to give into this pressure any longer.

I've been trying to move this project to compile on MinGW using either CMake or qmake so that we can move away from Visual Studio completely and develop and debug the entire project from within Qt Creator. Naturally, qmake would have been the preferred choice since it comes with every Qt bundle for Windows, and win32_utf8 actually did build nicely with it.

However, since all of our dependencies use CMake, wouldn't it be great if we could just generate a superproject and it just builds without requiring any changes to the existing submodules? Well, as it turns out, libpng requires a compiled zlib at, uh, CMake time, not at libpng compile time. To find the path, libpng's CMakeLists.txt does

find_package(ZLIB REQUIRED)

which ends up pulling a random zlib1.dll from my system, then tries to link that statically (yes) into the compiled libpng16.dll, which of course fails. Manually specifying ZLIB_ROOT or setting CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH in CMakeLists.txt? Didn't do a thing.

The CMake integration into Qt Creator is not exactly the best either. Leaving aside the fact that you have to install CMake separately, you don't automatically get Debug and Release build configurations as with qmake, unless you manually create a new build tree and remember to manually mumble the magic -DCMAKE_BUILD_TYPE=Release incantation.

Also, is this some kind of a joke?

At that point, I'm beginning to wonder why we should even change to a build system that is less understood within the active development team to begin with, only to effectively replace our perfectly working build with some auto-generated vomit. Let's look at the arguments brought forth by the CMake proponents:

• Visual C++ does not support C99 and C11
  • Actually, as of Visual C++ 2013, everything we could ever want from C99 is supported – _Bool, compound literals, designated initializers and variable declaration placement – in addition to the C99 (and even C11) features that have already been there.
• MSBuild sucks because it uses XML
  • If we criticized everything based on the first superficial annoyance, we wouldn't be getting anywhere. Like, how about we don't use Qt for the GUI because C++ is terrible? (The alternative would have been .NET, but even I don't hate obnoxious *nix users that much.) Or how about we stop patching Touhou entirely because we'll only be ever catching up to ZUN and Tasofro, when all we actually want is Touhou being open-source? (Oh, wait…)
• MSBuild sucks for open-source projects because it's not portable to different systems
  • Sure, if you've only ever seen .vcxproj files as the auto-generated garbage vomited out by CMake. By the same token, I could say that plain Makefiles are universally bad, because surely, they always look like the auto-generated garbage vomited out by autotools, right? In fact, if you use its features, MSBuild is probably the most portable build system that is not a Makefile generator. Yes, right now, the Visual Studio projects still require some manual configuration to set your current local paths for Jansson, zlib and libpng. However, I can easily change the project files to actually use the Git submodules we've decided to add in order to have true one-click builds from a fresh Visual Studio installation, and that's what I'm going to do next.
• Why are you advocating IDEs, you n00b, learn to Makefile!
  • ReC98 uses a Makefile, and this was a conscious choice in order to reduce build times. With that project, we don't care that much about debugging a running game since we can't do that through DOSBox anyway.
• But CMake is The Future™!
  • Well, I for one hope that a few years for now, we'll all be writing our low-level systems code in Jai instead, and use more appropriate languages for whenever we don't have to interact with the OS directly. I for one am going to early-adopt the fuck out of Jai once it comes out to make sure this happens. It's also the language I'm going to write the ReC98 port in.
• But supporting alternative compilers is good!
  • It's not. By introducing a choice between two compilers, one of them will invariably become the preferred choice, with the other being less supported, especially with a development team as small as ours. Again, this is not a cross-platform project, and we should be happy that it isn't.
• But we'll need to run moc in the future!
  • Which we will also be able to do from MSBuild.
• But we might want to use continuous integration in the future!
  • And MSBuild is exactly what AppVeyor supports by default.
• *But I want to develop on nix!
  • Can you develop this on *nix? Can you compile the whole project, then easily attach a debugger to the patched game, single-step through it, look at its memory and registers, and do the same for thcrap itself, preferably without having to drop down to assembly? If you can, please upload a video of yourself recreating patch support for any one game from scratch with this setup, and I'll reconsider.
    I get that you might only be interested in doing GUI development, which you can totally do on *nix, without even requiring Wine. But in that case, the build system is completely irrelevant anyway since you won't actually call back into any of the existing thcrap code, and can use whatever build system you want to for your work.
• But Visual Studio is not free software!
  • Excuse me, but this is the wrong project for comments like this.

Therefore, I'm closing this for now. This has sucked out enough time, productivity and momentum. If you still believe that either CMake or qmake would be a sensible choice for this project, go ahead, create a working build, and send a pull request, but I'm not going to waste any more time on this, and neither should anyone else.

[kitlith]

Would it be worth revisiting cmake? Things seem to have changed (at least a little bit) over the last 4 years.

• The specific issue with libpng was fixed 2 years ago (barring complaints of how meh this solution is and how meh CMake is, which I understand -- I'm not a fan of CMake either, but it works)
• As of VS 2017 Visual Studio supports CMake out of the box.
• Last time I attempted to find anything that supported MSBuild for linux it seemed to be exclusive to C#/.net. (As a side note, that's also apparently not too bad on linux nowadays between .net core and mono)
  • (this comes from experience, as a teacher of mine insisted on every project sent to them being a VS project. I'm not saying it doesn't exist, but it is at least not easy to find, and I ended up getting the teacher to agree to CMake instead since VS supported it.)
  • fwiw this is the only thing close to a 'sticking point' for me, and I'm sorry if there's something that exists that i've completely missed.

As for the developing on *nix point, the most I can say at this point is that since winedbg exists, I'd guess that it's possible, but I don't have the experience at the moment to be able to say "yes i'd be able to do that."

fwiw I'm willing to work on porting the build system to cmake (by) myself -- I just want to make sure that it's not going to be rejected out of hand.

[brliron]

• 1st, there is what you can call "religious reasons". I don't like cmake, because I struggled to build cmake-based projects in the past.
• On the other hand, cmake support in Visual Studio is a big upside. Our current setup is "install VS 2019, git clone --recursive, click on the build button, and it works". If we can have the same setup with cmake files, it could be acceptable.
• What about build times? I guess they don't increase much?
• Does cmake gives us enough control? For example, the project release needs to be built with the Visual Studio 2017 compiler (v141_xp, you can install it from VS2019 by checking a box) because that's the last one to support XP. And 2 projects need to be build without the CRT (because they will install it).
• Does our whole code compile on MinGW? IIRC a few parts don't. If we're only going to support VS, no need to switch to cmake.
• The points from nmlgc about some compilers being less supported and about the current team knowing msbuild more than cmake still apply.
• I don't think I've seen anyone ask for a Linux build in a few years, AFAIK all our devs are fine working on Windows.
• And the religious reasons from above still apply and add an obvious bias to my arguments.

So I'm not totally against the idea, but I'm not a fan of it.

[kitlith]

Let's see, in order:

• Totally understand, I've had my difficulties too, but it's mostly been balanced out by things just working and other build systems just not working.
• Only difference that I remember for building is opening the project -- since there's no project file per-se, you need to go into VS and open the folder. I'll dig into my notes from around then to make sure.
• Don't know. Wouldn't expect it to be increased by much, but it is a meta build system.P
• I believe so. I don't remember why, but I had to tweak something about this for my class so that we were using a compiler set that was both on the teacher's computer and on the lab machines. Again, I'll go look at notes.
• Don't know, I haven't tried yet. I don't have a windows box, combined with not having msbuild (for C++). I'd suspect it'd be possible to sprinkle a few compiler-specific defines if needed.
  • I'm going to look again at msbuild on linux for C++ now that I'm working with projects that don't need to be generated by myself, as I remember now that was the other issue I encountered. It's possible that this conversation is unnecessary in that case.
• Understood.
• Not surprised, I'm well aware I'm an odd person out in wanting to do everything remotely possible on linux instead of windows.
  • Only real other 'benefit' of being able to build on linux is the possibility of building natively for linux w/ the addition of winelib or smth, but I'm not going to get my hopes up for that.
• Understood.

In short, I'll dig into my notes and try some things.

[kitlith]

Sorry, this ended up at the bottom of my list, but I went to look it up again because of another project:

https://github.com/roozbehid/dotnet-vcxproj lets you build with GCC using msbuild/the dotnet cmdline tool on linux and other platforms, assuming that the rest of the codebase supports it.

[brliron]

That could work, I'll give it a try eventually

[kitlith]

I had issues with the thing i tried it with that I didn't know how to fix (it wasn't passing GCC any include directories, and it wasn't acknowledging that I was trying to compile a shared library) so I fell back to a quick Makefile. I suppose I should leave some issues on the repo, now that I'm not banging my head against the wall at 2AM.