The International Simutrans Forum

 

Author Topic: CMake build support for Extended  (Read 714 times)

0 Members and 1 Guest are viewing this topic.

Offline ceeac

  • Devotee
  • *
  • Posts: 203
CMake build support for Extended
« on: October 17, 2020, 07:22:19 PM »
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
« Last Edit: October 19, 2020, 09:43:24 PM by ceeac »

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 20274
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: CMake build support for Extended
« Reply #1 on: October 17, 2020, 09:26:16 PM »
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?

Online freddyhayward

  • Devotee
  • *
  • Posts: 437
  • Languages: EN
Re: CMake build support for Extended
« Reply #2 on: October 18, 2020, 10:13:13 AM »
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.

Offline Roboron

  • Devotee
  • *
  • Posts: 154
    • Las Galácticas Aventuras de Komoyo Diga
  • Languages: ES, EN
Re: CMake build support for Extended
« Reply #3 on: October 18, 2020, 10:58:42 AM »
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.

Offline Ranran

  • Devotee
  • *
  • Posts: 1219
  • Languages: ja
Re: CMake build support for Extended
« Reply #4 on: October 18, 2020, 11:12:47 AM »
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...

Online freddyhayward

  • Devotee
  • *
  • Posts: 437
  • Languages: EN
Re: CMake build support for Extended
« Reply #5 on: October 18, 2020, 11:16:21 AM »
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.

Offline Roboron

  • Devotee
  • *
  • Posts: 154
    • Las Galácticas Aventuras de Komoyo Diga
  • Languages: ES, EN
Re: CMake build support for Extended
« Reply #6 on: October 18, 2020, 11:35:27 AM »
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.

Online freddyhayward

  • Devotee
  • *
  • Posts: 437
  • Languages: EN
Re: CMake build support for Extended
« Reply #7 on: October 18, 2020, 11:39:54 AM »
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 :/

Offline Roboron

  • Devotee
  • *
  • Posts: 154
    • Las Galácticas Aventuras de Komoyo Diga
  • Languages: ES, EN
Re: CMake build support for Extended
« Reply #8 on: October 18, 2020, 11:54:24 AM »
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.

Online freddyhayward

  • Devotee
  • *
  • Posts: 437
  • Languages: EN
Re: CMake build support for Extended
« Reply #9 on: October 18, 2020, 12:25:21 PM »
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.

Offline Roboron

  • Devotee
  • *
  • Posts: 154
    • Las Galácticas Aventuras de Komoyo Diga
  • Languages: ES, EN
Re: CMake build support for Extended
« Reply #10 on: October 18, 2020, 12:50:25 PM »
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...

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 20274
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: CMake build support for Extended
« Reply #11 on: October 18, 2020, 12:53:54 PM »
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.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 20274
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: CMake build support for Extended
« Reply #12 on: October 18, 2020, 12:55:02 PM »
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?

Offline Ranran

  • Devotee
  • *
  • Posts: 1219
  • Languages: ja
Re: CMake build support for Extended
« Reply #13 on: October 18, 2020, 01:10:09 PM »
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.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 20274
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: CMake build support for Extended
« Reply #14 on: October 18, 2020, 01:54:28 PM »
Interesting and even more confusing - the error reported by Ranran, being:

Code: [Select]
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.

Offline Matthew

  • *
  • Posts: 419
    • Japan Railway Journal
  • Languages: EN, some ZH, DE & SQ
Re: CMake build support for Extended
« Reply #15 on: October 18, 2020, 03:44:25 PM »
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.

Offline Matthew

  • *
  • Posts: 419
    • Japan Railway Journal
  • Languages: EN, some ZH, DE & SQ
Re: CMake build support for Extended
« Reply #16 on: October 19, 2020, 11:54:20 AM »
Thirdly, I want to clarify that I have understood this step in the tutorial correctly:

Quote
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]
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. :o It's a small world!

Code: [Select]
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]
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)
« Last Edit: October 19, 2020, 12:07:45 PM by Matthew »

Offline Freahk

  • Devotee
  • *
  • Posts: 1325
  • Languages: DE, EN
Re: CMake build support for Extended
« Reply #17 on: October 19, 2020, 01:19:44 PM »
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.

Offline ceeac

  • Devotee
  • *
  • Posts: 203
Re: CMake build support for Extended
« Reply #18 on: October 19, 2020, 09:37:25 PM »
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.

Offline Matthew

  • *
  • Posts: 419
    • Japan Railway Journal
  • Languages: EN, some ZH, DE & SQ
Re: CMake build support for Extended
« Reply #19 on: October 20, 2020, 11:27:25 AM »
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.

Quote from: ceeac
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?

Quote
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]
   <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?

Offline Ranran

  • Devotee
  • *
  • Posts: 1219
  • Languages: ja
Re: CMake build support for Extended
« Reply #20 on: October 20, 2020, 01:33:03 PM »
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]
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]
« Last Edit: October 20, 2020, 05:10:16 PM by Ranran »

Offline ceeac

  • Devotee
  • *
  • Posts: 203
Re: CMake build support for Extended
« Reply #21 on: October 22, 2020, 07:05:34 PM »
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]
#!/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]
friend void swap<>(sparse_tpl<T>& a, sparse_tpl<T>& b);
with this one (note the double colons):
Code: [Select]
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).

Online freddyhayward

  • Devotee
  • *
  • Posts: 437
  • Languages: EN
Re: CMake build support for Extended
« Reply #22 on: October 22, 2020, 09:03:01 PM »
This is unrelated to the recent replies here, but I have found that the build crashes unless SIMUTRANS_USE_FREETYPE is explicitly disabled.

Offline Ranran

  • Devotee
  • *
  • Posts: 1219
  • Languages: ja
Re: CMake build support for Extended
« Reply #23 on: October 23, 2020, 12:21:51 AM »
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]
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]
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.

Offline ceeac

  • Devotee
  • *
  • Posts: 203
Re: CMake build support for Extended
« Reply #24 on: Yesterday at 05:28:04 PM »
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.

Offline Ranran

  • Devotee
  • *
  • Posts: 1219
  • Languages: ja
Re: CMake build support for Extended
« Reply #25 on: Yesterday at 10:14:36 PM »
Quote
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.

EDIT:
James's "merge-from-standard-8434" branch also seems to indicate some errors.
https://github.com/jamespetts/simutrans-extended/runs/1304951303
« Last Edit: Today at 03:13:10 AM by Ranran »

Online freddyhayward

  • Devotee
  • *
  • Posts: 437
  • Languages: EN
Re: CMake build support for Extended
« Reply #26 on: Yesterday at 11:07:02 PM »
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.