CMake build support for Extended

[ceeac]

With CMake build support merged as of commit 641af4e, I want to open this thread to talk about the current state of CMake build support for Extended, and also to provide some instructions to facilitate building Extended using CMake on Linux, macOS and Windows. This post consists of two parts: "Why?" and "How?". If you just want to build Simutrans-Extended, skip to the "How" part below.



CMake: Why?
The main problem is that in my opinion Extended has far too many build systems at the moment. From a quick glance at the sources, apart from CMake there are 3 different Visual Studio projects, 1 Eclipse project, a Makefile, an autoconf script, and several more project files and  Makefiles to build makeoj and nettool. My intention is to eventually replace all the different build systems by CMake which generates the Makefiles/project files/whatever of your choice; additionally for Visual Studio, the goal is to auto-download and auto-update all required dependencies using vcpkg so the dependencies no longer need to be updated manually.

What currently works or should work (see also the GitHub Actions CI here):

• Compiling on Linux
• Compiling on macOS
• Cross-compiling Linux -> Windows using MinGW GCC cross-compiler
• Compiling on Windows using Visual Studio + dependencies installed via vcpkg
• Running the game on Linux

What currently works only partially, does not work, or has not been tested:

• Running the game on Windows (It worked when I tested it back in August using Visual Studio, but things might have changed)
• Running the game on macOS (not tested as I don't have a Mac)
• Compiling on Windows using MinGW GCC (Not tested so far)
• Packing a compiled package on all platforms (not yet implemented)
• Auto-installing dependencies via CMake (not yet implemented)

CMake: How?
This part provides basic preliminary "build from scratch" instructions on Linux, macOS and Windows.
Note that these might not yet work 100%. Some tinkering may still be required.

(Last updated 2020-10-19)

Linux (Debian/Ubuntu, other distributions are analogous):

• Install dependencies:
    $ sudo apt install git cmake build-essential g++ zlib1g-dev libbz2-dev libpng-dev libsdl2-dev libsdl2-mixer-dev libfreetype-dev
  
• cdinto to your favourite development directory
  
• Clone Simutrans-Extended:
    $ git clone https://github.com/jamespetts/simutrans-extended
  
• Make build directory:
    cd simutrans-extended && mkdir build && cd build
  
• Generate Makefiles for a freetype+sdl2_mixer enabled build:
    $ cmake .. -DCMAKE_BUILD_TYPE=Release -DSIMUTRANS_BACKEND=mixer_sdl2 -DSIMUTRANS_USE_FREETYPE=ON
  
• Compile:
    $ make -j$(nproc)
  
• Download pakset:
    $ cd ../simutrans && ../get_pak.sh
  
• Play:
    $ ../build/simutrans/simutrans-extended -use_workdir
  

macOS (Note that this is different from the macOS CI build since we can just use Homebrew-supplied SDL2):

• Install Homebrew (brew.sh)
  
• Install dependencies via Homebrew
    $ brew install git cmake g++ sdl2 sdl2_mixer freetype
  
• Clone Simutrans-Extended:
    $ git clone https://github.com/jamespetts/simutrans-extended
  
• Make build directory:
    $ cd simutrans-extended && mkdir build && cd build
  
• Generate Makefiles for a freetype+sdl2_mixer enabled build:
    $ cmake .. -DCMAKE_BUILD_TYPE=Release -DSIMUTRANS_BACKEND=mixer_sdl2 -DSIMUTRANS_USE_FREETYPE=ON
  
• Compile:
    $ make -j$(sysctl hw.nlogicalcpu)
  
• Download pakset:
    $ cd ../simutrans && ../get_pak.sh
  
• Play:
    $ ../build/simutrans/simutrans-extended -use_workdir
  

Windows, MSVC/Visual Studio

• Download and install Visual Studio (https://visualstudio.microsoft.com/downloads/, make sure to install the "Desktop C++" feature)
• Download and install CMake (https://cmake.org/download/, see the "Latest Release" section)
• Download and install Git For Windows (https://gitforwindows.org/)
• Open a new Git Bash in your favourite development directory
• Clone Simutrans-Extended:
    $ git clone https://github.com/jamespetts/simutrans-extended
  
• Make build directory:
    $ cd simutrans-extended && mkdir build && cd build
  
• Clone and install vcpkg:
    $ git clone https://github.com/microsoft/vcpkg
    $ ./vcpkg/bootstrap-vcpkg.bat -disableMetrics
  
• Install dependencies:
    $ ./vcpkg/vcpkg --triplet x64-windows install zlib bzip2 freetype sdl2 sdl2-mixer
  
• Generate Visual Studo project files (you may need to specify the full path to cmake.exe, depending on your setup):
    $ cmake.exe .. -G "Visual Studio 16 2019" -A x64 -DCMAKE_TOOLCHAIN_FILE=./vcpkg/scripts/buildsystems/vcpkg.cmake -DSIMUTRANS_BACKEND=mixer_sdl2 -DSIMUTRANS_USE_FREETYPE=ON
  
• Open Simutrans-Extended.sln, build and run

[jamespetts]

This is very interesting and helpful, thank you. I imagine that we will have to have a gradual transition to this new system. Do you envisage this being used for the automated nightly builds?
Also, is this related to the CI builds that have been set up?

[freddyhayward]

I get a floating point exception using the linux build. The loading bar appears with no text, then crashes. It also seems to enable midi by default taking several minutes to load. I had neither of these problems using plain make or Freahk's cmake configuration.

[Roboron]

It also seems to enable midi by default taking several minutes to load.

This is a problem with SDL_mixer, nothing to do with this. Again, the fluidsynth music backend aims to solve this problem in the future.

[Ranran]

It doesn't seem to work properly on my branch that is incorporating from the standard. Reverting it eliminates errors.
Sadly I can't repair it myself...

[freddyhayward]

This is a problem with SDL_mixer, nothing to do with this. Again, the fluidsynth music backend aims to solve this problem in the future.

It must be relevant if SDL_mixer is being used by default.

[Roboron]

It must be relevant if SDL_mixer is being used by default.

I don't understand. Of course it is used by default, because it is the only default you can use now. Not doing so would be generating a version without music support, and that's not what a "default version" should be doing.

[freddyhayward]

I don't understand. Of course it is used by default, because it is the only default you can use now. Not doing so would be generating a version without music support, and that's not what a "default version" should be doing.

Neither the builds on http://bridgewater-brunel.me.uk/downloads/, nor Freahk's cmake configuration, nor any other configuration I have used until now, has ever had this problem. And it can be hardly called 'music support' when one has to delete all the music to load the game in reasonable time. Sorry about my tone :/

[Roboron]

nor any other configuration I have used until now, has ever had this problem

This problem can be reproduced (provided you set the envoriment variable, you have fluidsynth installed, and the necessary version of sdl_mixer) on builds generated by distros (Debian, Ubuntu, Arch) since they are all using sdl_mixer for obvious reasons. Maybe for a nightly build you have the luxure of generating a build without sdl_mixer or miniupnpc, but not for an stable release.

And it can be hardly called 'music support' when one has to delete all the music to load the game in reasonable time. Sorry about my tone :/

I totally agree with you, but the way to solve this is not to ship a game without music, but to fix the music. That's what I have been doing.

[freddyhayward]

I totally agree with you, but the way to solve this is not to ship a game without music, but to fix the music. That's what I have been doing.

I appreciate that, but it isn't here yet. It doesn't make sense to enable something broken by default (when it has been happily disabled for years) just because a fix is being worked on.

[Roboron]

I appreciate that, but it isn't here yet

Actually, it is. The backend works and code is ready to be merged. I could prepare a patch for Extended easily, and Extended could get rid of the SDL_mixer dependency, forever, just today (although it will add the fluidsynth dependency), if you want. That would simplify the build requirements.

The reason the patch is not yet "complete" is because it is lacking an UI to select soundfonts (to be more userfriendly), but that's only relevant for Windows users really (distributions ship default soundfonts), but Windows is using another non-sdl_mixer backend (w32 midi) by default anyway...

[jamespetts]

It doesn't seem to work properly on my branch that is incorporating from the standard. Reverting it eliminates errors.
Sadly I can't repair it myself...

Interesting - what problems were you getting? I wonder whether those are the same problems that I am getting compiling your branch with Visual Studio? I have been updating my own branch with your mergings to match the master branch, so this CMake code will be part of that; if there is a compile error with both combined, it is possible that that is the cause of the difficulty that I have been having.

[jamespetts]

Actually, it is. The backend works and code is ready to be merged. I could prepare a patch for Extended easily, and Extended could get rid of the SDL_mixer dependency, forever, just today (although it will add the fluidsynth dependency), if you want. That would simplify the build requirements.

The reason the patch is not yet "complete" is because it is lacking an UI to select soundfonts (to be more userfriendly), but that's only relevant for Windows users really (distributions ship default soundfonts), but Windows is using another non-sdl_mixer backend (w32 midi) by default anyway...

I wonder whether we should start a separate topic on this subject?

[Ranran]

what problems were you getting?

This is the case when the master branch has been merged.
https://github.com/Ranran-the-JuicyPork/simutrans-extended/runs/1270750597

Reverting the master branch merge seems to work fine.
https://github.com/Ranran-the-JuicyPork/simutrans-extended/runs/1271020450

Both are fine for me to compile with MSVC myself.

[jamespetts]

Interesting and even more confusing - the error reported by Ranran, being:

Code Select Expand


undefined reference to `virtual thunk to gui_aligned_container_t::get_max_size() const'

is another, but different, linker error relating to undefined references.

I am really not sure what to make of this.

[Matthew]

Firstly, I am very grateful to ceeac for undertaking the project of improving the Simutrans-Extended build process. I have spent some time trying to understand makefiles recently and it was not a pleasant experience. I am especially grateful that they have taken the time to write this in the form of a tutorial.

Secondly, I have tried following the tutorial for Visual Studio.* Most of it was delightfully straightforward, but there was one early problem. The CMake and Git for Windows installation processes all ask configuration questions (in the case of Git, many configuration questions). I followed all the defaults as I thought that was ceeac's likely intention. One of these came back to bite me though. CMake asks whether it should be added to the system PATH or the PATH for the present user. I chose "No", the default option, and this caused me much grief later, as predicted by the instruction that "(you may need to specify the full path to cmake.exe, depending on your setup)". I wasn't sure whether the path setting was a Bash-specific setting or Windows-wide, and I tried at the command line in Git Bash for Windows, PowerShell, and cmd.exe, none of which worked. It turned out that you can set it through the GUI (in Windows 10, This PC -> right-click -> Properties -> Environment Variables), but it does not take effect until you close the Environment Variables window and/or open a new Git Bash for Windows terminal. So I recommend that the tutorial step about installing CMake is updated to recommend that CMake is added to the system path, unless this is expected to have other negative effects.

(Points three and four will follow later when I have more time)

* Full disclosure: I had already installed Visual Studio 2019 Community Edition and cloned my Simutrans-Extended fork using VS' internal git functionality. But I had not built Sim-Ex before because I didn't have the required dependencies. I updated VS and updated my main branch to  James' main branch before following the rest of the tutorial.

[Matthew]

Thirdly, I want to clarify that I have understood this step in the tutorial correctly:

Make build directory:
  cd simutrans-extended && mkdir build && cd build

This means that the CMake build system and the vcpkg repository are both inside the simutrans-extended repository. Is that the desired result? I can see the logic in having the simutrans-extended dependencies to be in the same directory as the main code, and observe that Sim-Ex's .gitignore will exclude the build directory. But as a newbie, putting one (external) repo inside another seemed an odd thing to do.

Fourthly, I had two major errors at the installation of the Visual Studio project files.

Code Select Expand

Could NOT find CCache (missing: CCache_EXECUTABLE)
According to the Repology index and the vcpkg ports directory, the CCache package is not available from vcpkg. There is an upstream binary build here, but that subverts the goal of auto-installing all required dependences. However, I notice that in the CMakeLists.txt file, there is a section called if (CCache_FOUND), so can I take it that this package is not actually required for building Simutrans-Extended?

By the way, the top Google link for this error message leads to this bug report, which was resolved by a user called ceeac. It's a small world!

Code Select Expand

CMake Error at C:/Program Files/CMake/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:165 (message):
  Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR)

This is surprising, because vcpkg did not report any problem installing ZLIB and the package appears to be correctly installed:



The problem is discussed in this Stack Overflow question, which unfortunately has multiple viable solutions. Based on Josh's answer, it would be possible to resolve the issue by adding a line such as this to the CMakeLists.txt file:

Code Select Expand

set(ZLIB_ROOT build/vcpkg/zlib_x64-windows)

But that would only solve the issue for my 64-bit Windows installation, not for other platforms. So I wonder whether ceeac might kindly write a Find_Package(ZLIB) routine, as per the fourth comment to St Alphonzo's answer?

In a future post I will discuss further problems identified in my attempt to actually build Sim-Ex.

(Double post because new information)

[Mariculous]

The build dir should be excluded from git anyways using .gitignore.
The gitish solution to library dependencies are submodules. There might be reasons to not use this approach with CMake. In the end both should work just fine.

[ceeac]

so can I take it that this package is not actually required for building Simutrans-Extended?

Yes, it's optional; this is not an error but just a status message which indicates a non-required component was not found. CCache just speeds up re-compilation of programs by caching identical compiler output on disk. In fact, CCache does not work with Visual Studio at all last I checked so it might be best to disable searching for CCache in this case to not confuse the user.

This is surprising, because vcpkg did not report any problem installing ZLIB and the package appears to be correctly installed

This error appears because I forgot to add -DCMAKE_TOOLCHAIN_FILE=./vcpkg/scripts/buildsystems/vcpkg.cmake to the cmake call. I'll correct it in the original post.

This means that the CMake build system and the vcpkg repository are both inside the simutrans-extended repository. Is that the desired result?

Yes - You are also able to not put the build directory into the simutrans-extended repository but anywhere on your file system; in this case you need to call CMake with the actual path to the source files and not the parent directory, of course. If you have a system-wide installation of vcpkg (using vcpkg.exe integrate install, see the vcpkg insallation instructions), you can skip this step, but in this case the path to the toolchain file needs to be different. In any case vcpkg will be shipped with Visual Studio toward the end of the year according to the roadmap, but that does not apply if you are using an older version.

Do you envisage this being used for the automated nightly builds?
Also, is this related to the CI builds that have been set up?

Yes - you can download the builds from the artifacts section on the GitHub page right now, but given that I have not tried running them they will probably not work.
Switching the nightly builds to CMake should certainly be possible eventually, but the build process needs to be more polished beforehand.

It doesn't seem to work properly on my branch that is incorporating from the standard. Reverting it eliminates errors.

The GitHub Actions builds use CMake for building now because I enabled them on my branch before it was merged. Given that there are lots of "undefined reference" errors, you can try adding the relevant files to the CMakeLists.txt yourself - see the add_executable call, which should mirror the list of source files in the Makefile.

[Matthew]

The build dir should be excluded from git anyways using .gitignore.
The gitish solution to library dependencies are submodules. There might be reasons to not use this approach with CMake. In the end both should work just fine.

Yes - You are also able to not put the build directory into the simutrans-extended repository but anywhere on your file system; in this case you need to call CMake with the actual path to the source files and not the parent directory, of course. If you have a system-wide installation of vcpkg (using vcpkg.exe integrate install, see the vcpkg insallation instructions), you can skip this step, but in this case the path to the toolchain file needs to be different. In any case vcpkg will be shipped with Visual Studio toward the end of the year according to the roadmap, but that does not apply if you are using an older version.

Thanks to both of you for clarifying that the repositories were intended to nest. It's good to know that I understood the tutorial correctly and to hear that VS hopes to make the oddity go away eventually.

Yes, it's optional; this is not an error but just a status message which indicates a non-required component was not found. CCache just speeds up re-compilation of programs by caching identical compiler output on disk. In fact, CCache does not work with Visual Studio at all last I checked so it might be best to disable searching for CCache in this case to not confuse the user.

Thank you for the explanation. If it saves you time, then perhaps adding a line to the VS tutorial above saying "Ignore status messages about CCache, which is incompatible with VS" would be sufficient?

This error appears because I forgot to add -DCMAKE_TOOLCHAIN_FILE=./vcpkg/scripts/buildsystems/vcpkg.cmake to the cmake call. I'll correct it in the original post.

Thank you for suggesting a solution to this issue. I tested the new cmake parameters (in the same local repo as before) and the CMake status messages still say that it can't find ZLIB:



Rebuilding the solution confirms that VS can't find zlib.h yet.

Trying to understand this issue raises a question that might be relevant, might be irrelevant here but needs to be addressed anyway, or might be a total red herring. Looking in the Simutrans-Extended.vcxproj file, I found that it includes dozens of machine-specific absolute paths to source directories, such as:

Code Select Expand

   <LibraryPath Condition="'$(Configuration)|$(Platform)'=='Debug (SDL 2)|x64'">F:\My Documents\Development\Zlib\lib;
<LibraryPath Condition="'$(Configuration)|$(Platform)'=='Debug (SDL 2)|x64'">F:\My Documents\Development\Zlib\lib;F:\My Documents\Development\Lib Png\bin;F:\My Documents\Development\Simutrans\Open TTD binaries\OpenTTD essentials\win32\library;F:\My Documents\Development\Simutrans\SDL-1.2.13\lib;$(LibraryPath)</LibraryPath>
    <SourcePath Condition="'$(Configuration)|$(Platform)'=='Debug (SDL 2)|x64'">F:\My Documents\Development\Zlib\source;$(SourcePath)</SourcePath>
<AdditionalIncludeDirectories>F:\My Documents\Development\Zlib\include;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
    <LibraryPath Condition="'$(Configuration)|$(Platform)'=='Debug (SDL 2)|Win32'">C:\Users\James\Documents\Development\sdl2\lib\x86;..\bzip\lib;..\OpenTTD\win32\library;$(LibraryPath)</LibraryPath>

I guess that these paths were added through Visual Studio's GUI. If anyone who is testing this build process recognizes the paths above, they might think the build process works for everybody, when actually it only works on their machine. Perhaps the CMake effort will mean these manually-added paths can be phased out in time?

[Ranran]

The GitHub Actions builds use CMake for building now because I enabled them on my branch before it was merged. Given that there are lots of "undefined reference" errors, you can try adding the relevant files to the CMakeLists.txt yourself - see the add_executable call, which should mirror the list of source files in the Makefile.

thank you for your advice.
It is very helpful. Apparently the cause is that a new file has been added. I can repair it myself.

EDIT:
I've added the newly added file definitions to CmakeLists, but I still get an error that I haven't seen before.

Code Select Expand


D:\a\simutrans-extended\simutrans-extended\sys\simsys.cc(962,7): error C2039: 'string': is not a member of 'std' [D:\a\simutrans-extended\simutrans-extended\build\simutrans-extended.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.27.29110\include\iterator(21): message : see declaration of 'std' [D:\a\simutrans-extended\simutrans-extended\build\simutrans-extended.vcxproj]
D:\a\simutrans-extended\simutrans-extended\sys\simsys.cc(962,14): error C2065: 'string': undeclared identifier [D:\a\simutrans-extended\simutrans-extended\build\simutrans-extended.vcxproj]
D:\a\simutrans-extended\simutrans-extended\sys\simsys.cc(962,14): error C2146: syntax error: missing ';' before identifier 'param' [D:\a\simutrans-extended\simutrans-extended\build\simutrans-extended.vcxproj]
D:\a\simutrans-extended\simutrans-extended\sys\simsys.cc(962,14): error C3861: 'param': identifier not found [D:\a\simutrans-extended\simutrans-extended\build\simutrans-extended.vcxproj]
D:\a\simutrans-extended\simutrans-extended\sys\simsys.cc(963,2): error C2065: 'param': undeclared identifier [D:\a\simutrans-extended\simutrans-extended\build\simutrans-extended.vcxproj]
D:\a\simutrans-extended\simutrans-extended\sys\simsys.cc(964,23): error C2065: 'param': undeclared identifier [D:\a\simutrans-extended\simutrans-extended\build\simutrans-extended.vcxproj]
D:\a\simutrans-extended\simutrans-extended\sys\simsys.cc(964,22): error C2512: 'U16View::U16View': no appropriate default constructor available [D:\a\simutrans-extended\simutrans-extended\build\simutrans-extended.vcxproj]


[ceeac]

Thank you for suggesting a solution to this issue. I tested the new cmake parameters (in the same local repo as before) and the CMake status messages still say that it can't find ZLIB:

The following piece of code - slightly modified from the original post - works for me when building from scratch, can you check whether it works for you?

Code Select Expand


#!/bin/bash

set -ex

git clone https://github.com/jamespetts/simutrans-extended
pushd simutrans-extended
mkdir -p build
pushd build

git clone https://github.com/microsoft/vcpkg
pushd vcpkg
./bootstrap-vcpkg.sh -disableMetrics
./vcpkg.exe --triplet x64-windows install zlib libpng bzip2 sdl2 sdl2-mixer freetype
popd

cmake .. -DCMAKE_TOOLCHAIN_FILE=./vcpkg/scripts/buildsystems/vcpkg.cmake -G "Visual Studio 16 2019" -A x64 -DSIMUTRANS_BACKEND=mixer_sdl2 -DSIMUTRANS_USE_FREETYPE=ON

# Compile; optional
cmake --build . --target ALL_BUILD --config Release


If yes, then there a two possibilities: Either vcpkg does not work correctly when bootstrapping with bootstrap-vcpkg.bat from Git Bash, or CMAKE_TOOLCHAIN_FILE needs to be specified before the generator (-G) option. If the code does not work, then the error is probably specific to your setup.

Perhaps the CMake effort will mean these manually-added paths can be phased out in time?

That's the plan. In fact, the project files in the root directory will not work with CMake, only the ones that are generated by CMake in the build/ directory.

I've added the newly added file definitions to CmakeLists, but I still get an error that I haven't seen before.

Try replacing this piece of code at the end of sparse_tpl in sparse_tpl.h:

Code Select Expand


friend void swap<>(sparse_tpl<T>& a, sparse_tpl<T>& b);

with this one (note the double colons):

Code Select Expand


friend void ::swap<>(sparse_tpl<T>& a, sparse_tpl<T>& b);

GCC gets confused because of the using namespace std again (the error does not happen with clang).

[freddyhayward]

This is unrelated to the recent replies here, but I have found that the build crashes unless SIMUTRANS_USE_FREETYPE is explicitly disabled.

[Ranran]

Try replacing this piece of code at the end of sparse_tpl in sparse_tpl.h:

Thank you for checking it.


Applying it fixed some, but I get the following error in MSVC:

Code Select Expand

D:\a\simutrans-extended\simutrans-extended\gui\components\gui_numberinput.cc(59,90): error C2660: 'max': function does not take 1 arguments [D:\a\simutrans-extended\simutrans-extended\build\simutrans-extended.vcxproj]

Code Select Expand

D:\a\simutrans-extended\simutrans-extended\utils\../sys/simsys.h(12,10): fatal error C1083: Cannot open include file: 'zlib.h': No such file or directory [D:\a\simutrans-extended\simutrans-extended\build\nettools\nettool-extended.vcxproj]

However, when compiling with MSVC in my environment, such an error does not occur.

[ceeac]

Applying it fixed some, but I get the following error in MSVC:

Which branch? The build on the cmake-test branch fails because the integer variants of log2/log10 are missing in Extended (see simrandom.h/cc in Standard), and also because an #ifndef NETTOOL is missing somewhere (nettool does not need to include simsys.h IIRC)

This is unrelated to the recent replies here, but I have found that the build crashes unless SIMUTRANS_USE_FREETYPE is explicitly disabled.

It does not crash for me on Linux; instead, all text is absent. However, this problem is also present in the pre-CMake versions (tested with 6ee9fa21a), so this is probably not related to CMake.

[Ranran]

Which branch? The build on the cmake-test branch fails because the integer variants of log2/log10 are missing in Extended (see simrandom.h/cc in Standard), and also because an #ifndef NETTOOL is missing somewhere (nettool does not need to include simsys.h IIRC)

This branch.
https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/cmake-test

It's possible that there is a difference between the standard and extended code, or that I missed or did not merge the required commits correctly... I'll check it tonight.

[freddyhayward]

It does not crash for me on Linux; instead, all text is absent. However, this problem is also present in the pre-CMake versions (tested with 6ee9fa21a), so this is probably not related to CMake.

For me, on Linux, it only crashes on your cmake build (unless SIMUTRANS_USE_FREETYPE is explicitly set to OFF). It does not crash on regular make nor on Freahk's cmake build.

[Matthew]

The following piece of code - slightly modified from the original post - works for me when building from scratch, can you check whether it works for you?

Ceeac, thank you for taking the time to help with my compilation effort.

I saved the code (minus the optional part) as a Bash script and ran it in Git Bash for Windows in an empty directory. The first attempt failed because there was a space in the directory's name.

After fixing this, I tried again. The log has messages about not finding cached archives when building the vcpkg packages, but I guess that this is expected in a new installation. However, the attempt failed because MSVC could not build the test program:

Code Select Expand

CMake Error at C:/Program Files/CMake/share/cmake-3.18/Modules/CMakeTestCCompiler.cmake:66 (message):
  The C compiler
    "C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.27.29110/bin/Hostx64/x64/cl.exe"
  is not able to compile a simple test program.
  It fails with the following output:
    Change Dir: D:/BatchTestRepo/simutrans-extended/build/CMakeFiles/CMakeTmp
    Run Build Command(s):C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/MSBuild/Current/Bin/MSBuild.exe cmTC_5c96c.vcxproj /p:Configuration=Debug /p:Platform=x64 /p:VisualStudioVersion=16.0 /v:m && Microsoft (R) Build Engine version 16.7.0+b89cb5fde for .NET Framework
    Copyright (C) Microsoft Corporation. All rights reserved.
      Microsoft (R) C/C++ Optimizing Compiler Version 19.27.29112 for x64
      Copyright (C) Microsoft Corporation.  All rights reserved.
      testCCompiler.c
      cl /c /Zi /W3 /WX- /diagnostics:column /Od /Ob0 /D WIN32 /D _WINDOWS /D "CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /Fo"cmTC_5c96c.dir\Debug\\" /Fd"cmTC_5c96c.dir\Debug\vc142.pdb" /Gd /TC /errorReport:queue "D:\BatchTestRepo\simutrans-extended\build\CMakeFiles\CMakeTmp\testCCompiler.c"
      cmTC_5c96c.vcxproj -> D:\BatchTestRepo\simutrans-extended\build\CMakeFiles\CMakeTmp\Debug\cmTC_5c96c.exe
      '_VCPKG_PWSH_PATH-NOTFOUND' is not recognized as an internal or external command,
      operable program or batch file.
<snip>
  CMake will not be able to correctly generate this project.

I googled the command "_VCPKG_PWSH_PATH-NOTFOUND" and found a recent vcpkg bug report that suggests this error message is caused by an intermittent bug in the latest version of vcpkg. A patch to vcpkg to fix the bug was posted on Friday, so hopefully it will be merged soon.

So I will wait until the vcpkg bug is fixed before trying the Bash script again.

For reference, this log shows the full terminal output from running the script.

[Matthew]

tl;dr: Now the vcpkg bug is fixed, ceeac's script works, but some dlls have surprising names in a Debug build and the tutorial instructions should specify which solution file. The tutorial perhaps needs a post-build step (like distribution.sh).

Good news! I have made a Windows executable with CMake that nearly works! I will describe my blunders in full in case others face the same difficulties.

As the first step, the solution to the vcpkg bug discussed above has now been patched into its main tree, so that issue is out of the way.

Secondly, I then tried the script that ceeac kindly provided. At my first attempt at the "Generate Visual Studio project files" step, CMake could not find ZLib. This time (full log here) worked better:

Code Select Expand

-- Found ZLIB: optimized;D:/BatchTestRepo/simutrans-extended/build/vcpkg/installed/x64-windows/lib/zlib.lib;debug;D:/BatchTestRepo/simutrans-extended/build/vcpkg/installed/x64-windows/debug/lib/zlibd.lib (found version "1.2.11")

However, CMake...

Code Select Expand

-- Could NOT find MiniUPNP (missing: MiniUPNP_LIBRARY MiniUPNP_INCLUDE_DIR)
-- Could NOT find ZSTD (missing: ZSTD_LIBRARY ZSTD_INCLUDE_DIR)
-- Looking for pthread.h
-- Looking for pthread.h - not found

But unlike last time, CMake did not terminate this step early and created a solution file and other files in the \build directory. I don't think Sim-Ex uses ZSTD and I guessed that single-player games don't need MiniUPNP so I decided to continue.

Therefore there were now two solution files with very similar names: James' simutrans-extended\Simutrans-Extended.sln and CMake's simutrans-extended\build\simutrans-extended.sln. I assume that you (ceeac) expect us to use the second one, but I strongly suggest that you edit the tutorial to make that clear.

Thirdly, I opened the CMake solution file in VS, leaving it with the "Debug" configuration. The build completed without errors  and put the .exe in simutrans-extended\build\simutrans\Debug\. I tried running it and got this error message:



Looking in the directory suggested that some of the DLLs might be misnamed. EDIT: Apparently the *d.dll files are debug versions. Building a Release config avoids this.

Renaming SDL2d.dll did not work, but making a renamed copy did:



This time Simutrans started!



I then copied all those files into a directory containing all the proper support files (simutrans-extended/simutrans/). This got me further through the start-up process, but it still lacks font files and a pakset (apparently a Windows shortcut to a pakset is not sufficient).

That's all I have time to do today. Ceeac, thank you very much for your patience in holding my hand through the CMake process. I hope the feedback is helpful.

EDIT: I tried a Release build in a clean repository. When I copied everything from simutrans-extended\build\simutrans\Release into simutrans-extended\ and added a pakset there, Sim-Ex ran first time and loaded a Bridgewater-Brunel save without difficulty!



And on further study, it appears that CMakeLists.txt's install step and simutrans-extended\CMake\SimutransPack.cmake already include everything needed to complete a working a working installation, but VS' Release config does not include those steps.

(Double post for new information.)