Repository navigation
Make project buildable using MinGW toolchain #486
Description
Activity
Additionally, this will allow building in CLion, without the need to adapt to other toolchains.
Reacted by zzambersI support this effort very much. Do you expect any risk for breaking VS6 retail compatibility or should that be just fine?
Perhaps the right time to start this effort is after all VS2022 c++20 changes are merged. I expect it will be done this week for Zero Hour, Generals and all Tools.
You can already start it for Zero Hour though. That is merged now.
I will complete them in this order:
- Zero Hour (Done & Merged)
- Generals (Done)
- Zero Hour Tools (In progress)
- Generals Tools
Reacted by zzambers@zzambers would you like this issue assigned to you?
Reacted by zzambersI support this effort very much. Do you expect any risk for breaking VS6 retail compatibility or should that be just fine?
I hope not, I want to do minimal changes, just fix to build. (avoiding any invasive changes as much as possible)
Perhaps the right time to start this effort is after all VS2022 c++20 changes are merged. I expect it will be done this week for Zero Hour, Generals and all Tools.
You can already start it for Zero Hour though. That is merged now.
Ok, thanks.
I plan to make fixes toGeneralsMDand then try to "backport" changes toGenerals(by exporting patch from GeneralsMD and applying it to Generals). So this fits my planned workflow.How do you generate this patch? I have been transfering stuff by hand which took a while :D
Most of what your goals are have already been accomplished on my fork.
I'd suggest trying to build that one first, before jumping in and doing the work double.
Yes, we have a few problem with the keyboard under Win64 currently and the default configuration on Win32 has no sound, but it should already be buildable (and probably also playable) with MingW.At least I'm occasionally building with Clang on Win64.
How do you generate this patch? I have been transfering stuff by hand which took a while :D
You can for example generate patch between old and new revision using:
git diff old..new > changes.patchOr generate collection of patches for each commit by using:
git format-patch old..newYou can then play tricks with
git applyto apply them on different sub tree, such as:
git apply -p2 --directory=Generals changes.patchWhere
pparameter specifies how many directory elements to remove form beginning of file paths when applying patch, directory on contrary adds prefix to file paths in patch.Note that by default
git applyeither succeeds for whole change set or does not make any change and displays error. In case patch does not apply cleanly you can modify the behavior by adding--rejectargument togit apply. Then it applies changes where possible. For changes, which it fails to apply, it generates.rejfiles, you can then review those and decide what to do (then you can remove.rejfiles after you no longer need them).For more info just look into manual page for git command using e.g.
man git-applyin terminal or search it on the internet. There are many creative ways to use git command line tools. Maybe there is even fancier way to achieve this. :)Reacted by xezonReacted by DevGeniusCodeMost of what your goals are have already been accomplished on my fork. I'd suggest trying to build that one first, before jumping in and doing the work double. Yes, we have a few problem with the keyboard under Win64 currently and the default configuration on Win32 has no sound, but it should already be buildable (and probably also playable) with MingW.
At least I'm occasionally building with Clang on Win64.
Wow, I see you have been quite active in your fork. You are already porting Generals to SDL?
It is shame, that EA decided to make their repo read-only and not to continue development there. This way there is no official centralized place, where development would take place. Multiple people can then be doing same work without even knowing about each other...Maybe you can cherry pick things from Fighter19, but be aware that it will not be a 1 to 1 copy, because we currently still retain VS6 compatibility for a very specific use case. And we are currently building up both Generals and Zero Hour to have a reasonable foundation, but afterwards we concentrate on furthering Zero Hour development because this is where our focus and the multiplayer community is that we aim to serve.
Maybe you can cherry pick things from Fighter19, but be aware that it will not be a 1 to 1 copy, because we currently still retain VS6 compatibility for a very specific use case. And we are currently building up both Generals and Zero Hour to have a reasonable foundation, but afterwards we concentrate on furthering Zero Hour development because this is where our focus and the multiplayer community is that we aim to serve.
I see, I like conservative approach of this fork. I'll probably do required changes myself anyway, hopefully not that many should remain after VS2022 fix. (looking at it's diff brought lot of memories :))
How do you generate this patch? I have been transfering stuff by hand which took a while :D
You can for example generate patch between old and new revision using:
git diff old..new > changes.patchOr generate collection of patches for each commit by using:
git format-patch old..newbtw. patch can also be obtained from GitHub, by adding '.patch' to url. It works with links to commits, PRs even comparisons.
I have also been looking at cross-compiling using mingw64 on Linux, and would be happy to contribute if there's a good way to collaborate/coordinate on this.
I have also been looking at cross-compiling using mingw64 on Linux, and would be happy to contribute if there's a good way to collaborate/coordinate on this.
My current plan is to start with Zero Hour (game, in progress) then backport changes to Generals. Not sure how to work in parallel at this point, maybe later with tools.
- changed the title
[-]Make project buildable using MingGW toolchain[/-][+]Make project buildable using MinGW toolchain[/+]on Mar 27, 2025 git apply -p2 --directory=Generals changes.patch
This is amazing. I appended
--rejectand--whitespace=fix.@DevGeniusCode Can you please document this stuff in our wiki or link to resources?
Most of what your goals are have already been accomplished on my fork. I'd suggest trying to build that one first, before jumping in and doing the work double. Yes, we have a few problem with the keyboard under Win64 currently and the default configuration on Win32 has no sound, but it should already be buildable (and probably also playable) with MingW.
At least I'm occasionally building with Clang on Win64.
Im not able to reproduce your success. Your build tested 4days ago segfaults on me. There is build instructions missing. Dependency on a ms owned c++ package manager. Environment vars you need to set because otherwise the game can not init the gpu. (vulkan nvidia json path). It would help us linux devs alot if we could reproduce your work.
I would like to make Generals buildable using minGW (mingw-w64)
Background:
MinGW is open source project providing cross-platform suite/toolchain to build windows binaries (i.e. toolchain, based on GNU gcc + buinutils + windows headers etc). Can be used on many platforms including windows and linux. So this would make it possible to do build on other systems than window (such as linux, doing cross-compilation), and also drop dependence on proprietary software (for building). This can also serve as good intermediate step to eventual support for other platforms as build target. That would however need much more work and is out of scope of this effort.
Sub goals (many issues already raised by other people):
Making c++ portable/standard conforming
I have spend some time trying to fix these issues, but I see there is big overlap with ongoing effort to make game compile on VS2022/c++20. I basically faced all the same issues stated in PR as well. There will be more fixes necessary, to fix errors in GCC (like e.g. forward enum declarations etc.). But it will probably be better to wait for VS2022 work to be done, not to duplicate work.