Because of some problems with the macOS build of git master, I just modified it that instead of cloning the repo it just downloads the current master from https://github.com/geany/geany/archive/refs/heads/master.tag.gz. The tarball, however, doesn't contain a git repository and the build fails with ``` Program python3 found: YES (/Users/jhbuild/gtk/inst/bin/python3) Program rst2html found: NO Program rst2pdf found: NO Program git found: YES (/usr/bin/git) Running command: /usr/bin/git rev-parse --short --revs-only HEAD --- stdout ---
--- stderr --- fatal: not a git repository (or any of the parent directories): .git
../../../../gtk/source/geany-git/meson.build:170:1: ERROR: Command `/usr/bin/git rev-parse --short --revs-only HEAD` failed with status 128. ```
It appears that the problem is the line here which doesn't check if the repo exists (or recovers from the error):
https://github.com/geany/geany/blob/2509e21526d36034f5251381a76555e7300fbfc0...
Once we make a release, the release tarballs will suffer from the same problem so I think it's something that should be fixed.
@kugel- Since you are the meson expert, any idea what the best solution of this problem should be?
Probably should use `vcs_tag()` which looks for VCS info, or returns a specified fallback.
Well, the full thing is: https://github.com/geany/geany/blob/2509e21526d36034f5251381a76555e7300fbfc0...
So it's assuming that if the git program is *found*, geany itself is building from git. But this isn't a necessarily safe assumption... you can change that to: ```meson if git.found() and fs.exists('.git') ```
Which guarantees that geany itself is a git repository.
Although doing this at configure time will indeed become out of date after fetching updates and doing incremental rebuilds, so getting rid of the current approach and migrating to vcs_tag() might indeed be worth it.
I would have thought this would bite distro packagers, but maybe they are all still using autotools.
It is actually more likely that they are building in containers without git installed. :)
@kugel- Ping :-).
Since the tarballs of the release won't contain the git repository, this will have to be fixed somehow, otherwise meson build is going to fail.
Note, the "proper" way of telling if the build is in a git working dir is `git rev-parse --is-inside-working-dir` but googling shows that didn't behave itself for older (but still supported) git versions (it fataled instead of nicely printing "false") so for now #3578 seems a reasonable fix for release 2.0.
Closed #3424 as completed via #3597.
github-comments@lists.geany.org