-
-
Notifications
You must be signed in to change notification settings - Fork 43
Notes on Windows Compilation (WIP)
You will probably want to start with an existing branch where work has been put in towards getting Vega Strike to compile successfully on Windows. For example, this branch: https://github.com/stephengtuggy/Vega-Strike-Engine-Source/tree/sep-2020-windows-retry-sgt
On said branch, there is a PowerShell script in the script
folder called bootstrap.ps1
. It automates at least part of the process of installing the Vega Strike library dependencies using vcpkg. (vcpkg seems like the way to go, from what I can tell.)
Visual Studio 2017 was still available for download last time I checked, a few months ago. However, you may need to sign up for a free Microsoft account and MSDN/Visual Studio subscription first. Then I think it might be under Subscriber Downloads, or something like that.
One category of compile errors I was dealing with involved namespace collisions with Microsoft-provided libraries. Another was files #include
d with the folder prefixed at the beginning, when they shouldn't have been. I.e. #include <al/al.h>
instead of just #include <al.h>
. This form does not work with the folder structure that vcpkg creates for header files.
It will take a while to get through all these errors, but I think it will be worth it.
Oh, and when you install Visual Studio 2017, you'll want to select at least the "C++ - Desktop" and "Python" workloads. I also recommend installing CMake as an individual component from there. Although vcpkg comes with its own copy of CMake, and that's probably the one you should end up using. It's in one of the vcpkg binary sub-folders, I forget which one.
Then when you run CMake, you'll want to choose the vcpkg "toolchain," and the Visual Studio 2017 x86 (32-bit) generators. 32-bit, because the header files we're using are so old, they don't recognize 64-bit Windows properly.
There will probably be one dependency that appears to be missing. pkgconfig, or something like that. But it's actually present, in one of the vcpkg sub-folders. cmake just doesn't find it automatically for some reason.