Open AMDmi3 opened 9 years ago
Yes, this is a very good idea. I'll get working on that.
Allowing a complete coexistence with stratagus implies more than just renaming the binary actually. Everything would have to be renamed to ensure that there are no conflicts. The downside of this would be that the code base would grow incompatible with stratagus, if @Andrettin did something roughly like sed -i 's/stratagus/wyrmgus/g' *
.
It all boils down to how compatible you wish to remain with stratagus, to be able to include stratagus changes in wyrmgus. As far as distros and users are concerned, I think the simplest solution currently is to just build wyrmgus, and install manually the stratagus binary as /usr/games/wyrmgus
, without bothering about the other targets like png2stratagus (that would also conflict with a system-installed stratagus).
I see now that wyrmgus is in sync with stratagus 2.3.0 which was released recently, so that answers the question about making sure the engine can easily be synced with upstream.
A compromise that could make it easier to build and install wyrmsun/wyrmgus without touching too much the original stratagus files could be to do the following:
Allowing a complete coexistence with stratagus implies more than just renaming the binary actually. Everything would have to be renamed to ensure that there are no conflicts.
Please elaborate. For FreeBSD port, I could seemingly escape with just installing stratagus binary from wyrmgus as ${PREFIX}/bin/wyrmgus. Wyrmsun port installs wrapper which just calls wyrmgus on installed game data.
Allowing a complete coexistence with stratagus implies more than just renaming the binary actually. Everything would have to be renamed to ensure that there are no conflicts.
Please elaborate. For FreeBSD port, I could seemingly escape with just installing stratagus binary from wyrmgus as ${PREFIX}/bin/wyrmgus. Wyrmsun port installs wrapper which just calls wyrmgus on installed game data.
Exactly, but for such scenario you don't really need upstream to rename the binary. You just have to adapt your build script as you described. When I talk about "complete coexistence", I mean running make install
after building wyrmgus to have the engine and the corresponding development tools installed, as you would with a stratagus package. For example on Mageia the stratagus package comprises:
/usr/bin/png2stratagus
/usr/games/stratagus
/usr/sbin/metaserver
/usr/share/doc/stratagus/*
/usr/share/man/man6/stratagus.6.xz
So if one wanted to provide a full wyrmgus package, then the metaserver and png2stratagus binaries should also be renamed, etc.. Not that's it undoable though, it just makes syncing with upstream harder because of the rebranding.
Exactly, but for such scenario you don't really need upstream to rename the binary
Well, yes - I came with mentioned solution after I've opened the bug. Given that that is possible, I think minimizing changes with stratagus should come in the first place and this issue may be closed. Though when using git properly, maintaining changeset of either size is easy, but unfortunately that's not the case with wyrmgus as it's developed completely independent of upstream.
Back to the problem, I really like your solution:
Write a CMakeLists.txt script that would chain load the one in wyrmgus/CMakeLists.txt, but then use different installation instructions to install only the engine binary and give it a proper name, and install the game data at the same time
however the proper one would be of course merging all bits required for wyrmsun into stratagus.
From what I can see on current code, most of incompatibilities comes from "version.h" and autogen. This have other impacts that annoys me so Im working on a patch that may help this issue too.
wyrmgus needs to be able to coexist with stratagus so it is possible to install wyrmsun along with stratagus-based games on a same host. For that, engine binary should be renamed.