Closed felfert closed 2 years ago
When you say "source archive" what exactly are you referring to?
Huh? Don't you know the contents of your releases? I am referring to the source archives provided on your release page at the very bottom. There are two of them, named "Source code", One is a zip archive, the other one a tar.gz archive. This issue applies to both of them, because both contain the same directory hierarchy. The direct links are:
https://github.com/todbot/blink1-tool/archive/refs/tags/v2.2.0.zip
and
https://github.com/todbot/blink1-tool/archive/refs/tags/v2.2.0.tar.gz
To create a correct snapshot (archive) of your source tree, you should do something similar like you do already with the binary zip. e.g.:
GIT_TAG_RAW?=$(strip $(shell git tag 2>&1 | tail -1 | cut -f1 -d' '))
# deal with case of no git or no git tags, check for presence of "v" (i.e. "v1.93")
ifneq ($(findstring v,$(GIT_TAG_RAW)), v)
GIT_TAG_RAW:=v$(strip $(shell date -r . +'%Y%m%d' ))
endif
GIT_TAG?="$(GIT_TAG_RAW)"
distname=blink1-tool-$(GIT_TAG_RAW)
and then (requires GNU tar):
dist: distclean
rm -rf $(distname)
mkdir $(distname)
tar cf - --exclude=".git" --exclude=$(distname) . | tar xf - -C $(distname)
tar chzf $(distname).tar.gz $(distname)
zip -r $(distname).zip $(distname)
rm -rf $(distname)
Additional remark: In general, it is a very bad idea to use any git submodule and update it during build, because this makes reproducible builds impossible, as any thirdparty repo could have changed in the time between release (of your project) and time of actual build (later).
And of course, remove the git submodule --init or perhaps make it conditional, only if running inside a local git checkout (./.git exists)
Thank you for your clarification. I was checking to see if you were getting the source from a github downloads page or elsewhere. I was confused because if you were downloading from github, why not just do a checkout? You can get reproducible builds by checking out a specific version with git clone --branch 'v2.2.0' --depth 1 https://github.com/todbot/blink1-tool
Those github source zips are autogenerated by github and repo owners have no control over how they are generated. They are a snapshot of the repo. There's no way that I can embed hidapi in them.
The hidapi git submodule is of a very specific checkout (specifically https://github.com/libusb/hidapi/tree/f6d0073fcddbdda24549199445e844971d3c9cef ), so that builds are reproducible.
The blink1-tool
build system is currently designed to build statically, for several reasons: MacOS & Windows do not have a system hidapi, most Linuxes have very stale system hidapi, if at all.
To address your concerns, I've been working on a mechanism to detect if building from a non-git checkout and provide a hidapi download link.
Apologies this is causing you problems. I've tried to make the build process for blink1-tool
as simple as possible but your use case is totally one I hadn't considered.
Would you accept a PR, containing my above proposal introducing a make target "dist"? This would greatly ease things regarding packaging for various distros, because most of them (at least rpm and deb), usually expect source tarballs by default) The above dist target simply spits out source archives (tar and zip) which
I could also make the execution of git submodule --init conditional (only if a .git subdir exists)
Yes, I would greatly appreciate your expertise in this matter. Thank you.
Subject says it all: The build uses git in the prep target to update the hidapi submodule. This fails, because the tgz does (rightfully) neither contain a .git subdir and only an empty hidapi directory.
In order to do proper packaging (in my case on Fedora), the tgz needs to be self-contained or it probably should be possible to specify an external hidapi (e.g. Fedora34 has hidapi-devel-0.10.1-3.fc34.x86_64 available)