Descent3
Descent3 copied to clipboard
DescentDevelopers
Use Git commit head at title screen
Current builds use VER 1.5 at the lower right of the main menu. Can this be changed to show major and minor versions along with git commit heads for better version tracking?
This appears to be handled in Descent3/program.h.
I think an action in CMakeLists.txt would be needed to make this work. The version needs to be added as static test by modifying program.h each time it is compiled, rather than at runtime.
If this does get added, it would be nice if it was optional. In order words, I would want to be able to run cmake with something like -DSHOW_COMMIT=false to disable this feature. I know of at least two situations where a feature like this hasn’t worked well:
I’m the maintainer of Nixpkgs’s ECWolf package. ECWolf does something similar. Nixpkgs doesn’t bother cloning the entire ECWolf Git repository. It just downloads a tarball of the latest release. Git metadata isn’t included in the tarball, so ECWolf isn’t able to determine its Git commit. As a result, every ECWolf window ends up having “(<unknown version>)” in its title which is awkward an unhelpful. I’m also aware of a similar problem that used to exist with Arch Linux’s SCons package.
I want to eventually add Descent 3 to Nixpkgs, and I don’t want it to inadvertently contain an awkward placeholder string.
I’m the maintainer of Nixpkgs’s ECWolf package. ECWolf does something similar. Nixpkgs doesn’t bother cloning the entire ECWolf Git repository. It just downloads a tarball of the latest release. Git metadata isn’t included in the tarball, so ECWolf isn’t able to determine its Git commit. As a result, every ECWolf window ends up having “(
)” in its title which is awkward an unhelpful. I’m also aware of a similar problem that used to exist with Arch Linux’s SCons package.
+1. Similar process and potential issue for the FreeBSD ports tree
What if we were to automate creating a blank file, version (.txt but I would just leave the file extension blank), in the CI that gets done whenever a commit occurs? That avoids git metadata and at compile time cmakelists can check that file.
The workflow:
- Creates a version file (its local so can be in the generated artifacts)
- Adds the 40-digit git hash to it
- The game can reference this file for its version information (bypassing git metadata)
The CI has the ability to push to the repository on our behalf if the version file needs to be maintained upstream.
What if we were to automate creating a blank file,
version(.txt but I would just leave the file extension blank), in the CI that gets done whenever a commit occurs? That avoids git metadata and at compile time cmakelists can check that file.The workflow:
Creates a version file (its local so can be in the generated artifacts)
Adds the 40-digit git hash to it
The game can reference this file for its version information (bypassing git metadata)
The CI has the ability to push to the repository on our behalf if the
versionfile needs to be maintained upstream.
How would storing the Git commit hash in a file help?
What if we were to automate creating a blank file,
version(.txt but I would just leave the file extension blank), in the CI that gets done whenever a commit occurs? That avoids git metadata and at compile time cmakelists can check that file.The workflow:
- Creates a version file (its local so can be in the generated artifacts)
- Adds the 40-digit git hash to it
- The game can reference this file for its version information (bypassing git metadata)
The CI has the ability to push to the repository on our behalf if the
versionfile needs to be maintained upstream.How would storing the Git commit hash in a file help?
It bypasses git metadata which your tarball wouldn't receive. That allows the game to get the hash. If it can't find one then it can just return an empty string so nothing looks out of place.
It's just an idea, there are far more graceful methods like using a .cmake file.
It bypasses git metadata which your tarball wouldn't receive. That allows the game to get the hash. If it can't find one then it can just return an empty string so nothing looks out of place.
It's just an idea, there are far more graceful methods like using a .cmake file.
In this scenario, would the package builders be downloading CI artifacts instead of source tarballs?
If we are talking about package builders in terms of people maintaining .deb packages for Ubuntu for example, then no, they build everything from source. There are some exceptions to it: the non-free group.
