Open waarmond opened 3 weeks ago
That sounds like you have a shallow clone of the repository that doesn't include 16cd907fe7482cb54a7374cd28b8501f138116be, so version.sh
fails.
I haven't modified the script so it is also shared by a few other forks that are also available on the AUR (arch1t3ct, tstools) that should also have the same issue.
I think makepkg defaults to fully cloning source repositories unless DLAGENTS is set to change this behaviour (https://pacman.archlinux.page/makepkg.conf.5.html). If you're using a AUR helper I guess it could also be overriding it too.
(CC @pjeanjean in case I'm missing something about the AUR/Arch part of the issue)
I can't think of a good way to have a satisfying version string from a shallow clone of the repository, so that can't be easily changed (and I would assume it would also cause issues for other packages).
Now with a deep clone:
../src/version.cpp:79:9: error: return-statement with no value, in function returning 'int' [-fpermissive]
79 | return BUILD_GIT_VERSION_NUMBER;
| ^~~~~~
which I've patched away:
--- old/src/version.cpp 2024-06-05 19:48:52.804199104 +0200
+++ aegisub/src/version.cpp 2024-06-05 19:49:35.328154377 +0200
@@ -75,9 +75,5 @@
}
int GetSVNRevision() {
-#ifdef BUILD_GIT_VERSION_NUMBER
- return BUILD_GIT_VERSION_NUMBER;
-#else
- return 0;
-#endif
-}
+return 0;
+}
Well that should obviously not be patched this way.
In the build directory there is a git_version.h
header file that defines the variable. It is empty and that's where the issue is (EDIT: or rather, it is in the script that generates this file).
Perhaps share the build log.
I could not reproduce this specific issue with the PKGBUILD, but it needed some updates so I changed a few things. Maybe try to force a cleanbuild if the problem persists?
@waarmond if you want this issue to go anywhere can you try the latest PKGBUILD and share the build log?
Bonjour,
I'm using your AUR PKGBUILD against current sources