2 Commits

Author	SHA1	Message	Date
UdjinM6	f72650d2de	feat: Set client version for non-release binaries and version in guix based on git tags (#5653) ... ## Issue being fixed or feature implemented Client version string is inconsistent. Building `v20.0.0-beta.8` tag locally produces binaries that report `v20.0.0-beta.8` version but binaries built in guix would report `v20.0.0rc1-g3e732a952226a20505f907e4fd9b3fdbb14ea5ee` instead. Building any commit after `v20.0.0-beta.8` locally would result in versions like `v20.0.0rc1-8c94153d2497` which is close but it's still yet another format. And both versions with `rc1` in their names are confusing cause you'd expect them to mention `beta.8` instead maybe (or is it just me? :D ). ## What was done? Change it so that the version string would look like this: on tag: ~`v20.0.0-beta.8-dev` or `v20.0.0-beta.8-gitarc`~ `v20.0.0-beta.8` post-tag: ~`v20.0.0-beta.8-1-gb837e08164-gitarc`~ `v20.0.0-beta.8-1-gb837e08164` post-tag format is `recent tag`-`commits since that tag`-`g+12 chars of commit hash`-`dirty (optional)` ~-`dev or gitarc`~ ~`dev`/`gitarc` suffixes should help avoiding confusion with the release versions and they also indicate the way non-release binaries were built.~ Note that release binaries do not use any of this, they still use `PACKAGE_VERSION` from `configure` like before. Also, `CLIENT_VERSION_RC` is no longer used in this setup so it was removed. Few things aren't clear to me yet: 1. Version bump in `configure.ac` no longer affects the reported version (unless it's an actual release). Are there any downsides I might be missing? 2. Which tag should we use on `develop` once we bump version in configure? `v21.0.0-init`? `v21.0.0-alpha1`? 3. How is it going to behave once `merge master back into develop` kind of PR is merged? E.g. say `develop` branch is on `v21.0.0-alpha1` tag and we merge v20.1.0 from `master` back into it. Will this bring `v20.1.0` release tag into `develop`? Will it become the one that will be used from that moment? If so we will probably need another tag on `develop` every time such PR is merged e.g. `v21.0.0-alpha2` (or whatever the next number is). Don't think these are blockers but would like to hear thoughts from others. ## How Has This Been Tested? Built binaries locally, built them using guix at a specific tag and at some commit on top of it. ## Breaking Changes n/a ## Checklist: - [x] I have performed a self-review of my own code - [x] I have commented my code, particularly in hard-to-understand areas - [ ] I have added or updated relevant unit/integration/functional/e2e tests - [ ] I have made corresponding changes to the documentation - [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_	2024-01-11 21:43:42 -06:00
W. J. van der Laan	dfd1045284	Merge #21375: guix: Misc feedback-based fixes + hier restructuring ... 7476b46f1893a4858616d2a8456a7c43238851ed guix: Build dmg as a static binary (Carl Dong) 06d6cf6784421290e6235fe8684d5e08ed6f1b62 depends: libdmg-hfsplus: Skip CMake RPATH patching (Carl Dong) 65176ab5730dff34466caaecdd292625ef8294fc guix: Remove codesign_allocate+pagestuff from unsigned tarball (Carl Dong) ca85679eb43b8375a95d82101977829d08fb1e1b guix: Use clang-toolchain instead of clang (Carl Dong) 1aec0eda8fd31a57b0621eea616398017c2ead98 guix: Fallback to local build for substitute-enabled Guix users (Carl Dong) 1742f8e12d163852df09575e03edcd3db73198ee guix: Add early health check for guix-daemon (Carl Dong) c1ae726a13ecfa5e7e9fdc3030a8110b8bb263f8 guix: More thoroughly control native toolchain (Carl Dong) 39741128d3775d198dbee34dc827353bfd18acd8 guix: Supply --link-profile (Carl Dong) d55a1056ee565afed64e42d6f6efb6b0adc5599b guix: Add troubleshooting documentation entries (Carl Dong) 7f401c953f8bb3574cec48561e13ef3b47dedc6e guix: Adapt guix-build to prelude, restructure hier (Carl Dong) 4eccf063b252bfe256cf72d363a24cf0183e926e guix: Remove guix-build.sh filename extension (Carl Dong) 7753357a7bae98ec775c707b9dec4cea1e945802 guix: Add source-able bash prelude and utils (Carl Dong) e5b49a01f5d0f631e7f08f86ca8a2c2b8213319f guix: Create windeploy inside distsrc-* (Carl Dong) 3e9982ab3877eb8fe0a8c0cb3d847ac0913c7336 contrib: Silence git-describe when looking for tag (Carl Dong) d5a71e97853ea9e1b879e8c76bfb01d4bef33172 guix: Use --cores instead of --max-jobs (Carl Dong) Pull request description: This PR addresses a few hiccups encountered by the brave souls who've been experimenting with the Guix scripts: - Resolves confusion between `--cores=` and `--max-jobs=` - `guix`'s `--cores=` actually corresponds to make's `--jobs=`, so let's just control `--cores=` with our overridable env var - `git-describe` will scream `fatal: no tag exactly matches '<hash>'` when looking for a tag, but we don't care, so silence that - `windeploy/unsigned` should be inside `distsrc-*` and created idempotently (sorry I know this one annoyed people) - Add troubleshooting documentation to `README.md` - Add early health check for `guix-daemon` in case user forgot to start a `guix-daemon` - Depending on configuration, a `--fallback` flag may be needed to tell Guix to not fail if substitutes fail but fallback to building locally - `codesign_allocate` and `pagestuff` are now unnecessary for codesigning as we're now using `signapple` A few robustness changes are also included: - We supply the `--link-profile` flag, as some Guix packages may expect the profile to be available under `$HOME/.guix-profile` - We now clear and manually set all toolchain-related env vars (e.g. `C*_INCLUDE_PATH`) ourselves, after patching a Qt::moc bug - We use the native `clang-toolchain` package for darwin builds instead of `clang`, lining up with all our other toolchain packages. Finally, we restructure the guix building hierarchy such that it looks something like: ``` guix-build-<short-hash-or-version-tag> ├── distsrc-<short-hash-or-version-tag>-${HOST} │ ├── contrib │ ├── depends │ ├── src │ └── ... ├── distsrc-<short-hash-or-version-tag>-... └── output ├── dist-archive │ └── bitcoin-<short-hash-or-version-tag>.tar.gz ├── *-linux-* │ ├── bitcoin-<short-hash-or-version-tag>-*-linux-*-debug.tar.gz │ └── bitcoin-<short-hash-or-version-tag>-*-linux-*.tar.gz ├── x86_64-apple-darwin18 │ ├── bitcoin-<short-hash-or-version-tag>-osx64.tar.gz │ ├── bitcoin-<short-hash-or-version-tag>-osx-unsigned.dmg │ └── bitcoin-<short-hash-or-version-tag>-osx-unsigned.tar.gz └── x86_64-w64-mingw32 ├── bitcoin-<short-hash-or-version-tag>-win64-debug.zip ├── bitcoin-<short-hash-or-version-tag>-win64-setup-unsigned.exe ├── bitcoin-<short-hash-or-version-tag>-win64.zip └── bitcoin-<short-hash-or-version-tag>-win-unsigned.tar.gz ``` Separating guix builds by their version identifier (basically namespacing them) allows us to change the layout in the future without worry about potential naming conflicts. ACKs for top commit: sipa: ACK 7476b46f1893a4858616d2a8456a7c43238851ed laanwj: ACK 7476b46f1893a4858616d2a8456a7c43238851ed Tree-SHA512: 0e899aa941aafdf552b2a7e8a08131ee9283180bbef7334439e2461a02aa7235ab7b9ca9c149b80fc5d0a9f4bbd35bc80fcee26197c0836ba8eaf2d86ffa0386	2023-03-26 16:50:26 -05:00