I guess this just slipped through because it's a use case we never run into or test.
I have an easy way to reproduce this, so any fixes you push I can test if it fixes the issue!
How does one even fix this? I don't think we have control over the source tarballs.
According to https://mesonbuild.com/Reference-manual_functions.html#vcs_tag, you can actually probably use the fallback feature in vcs_tag() to add a fallback version, if either Git is not present or a git repo is not initialized + has no history. So a version of "2141" might suffice. At the end of the day, the main goal is to avoid that the fall back will use decimal points.
Thank you for implementing that change!
If the method of download is not related to Git, such as obtaining archive tarballs such as
https://github.com/HansKristian-Work/vkd3d-proton/archive/<git-hash>.tar.gz, there would be no git repo initialized in the root of the project. This causes an issue in the generation of vkd3d_build.h. Specifically, the generation suceeds, but the value it spits out causes a build failure as there is too many decimal points. For me, the value ends up being0x2.14.1when it likely wants to see a git hash instead.This issue seems related: https://github.com/HansKristian-Work/vkd3d-proton/issues/1289. This same issue was acknowledged, that the header file generation would be fixed. However, the issue remains. Is this planned to be fixed? Right now, my work around has been:
But that's a bandaid solution and doesn't properly generate an accurate version. It just hardcodes the version to be
0x0. Regardless, I don't think it should be assumed that when compiling the project that a git repository is initialized, that someone would have retrieved the source code in another method.Thanks in advance!