Created attachment 237540 [details] Patch for libcpuid Use upstream release archive as recommended by Porters Handbook USE_GITHUB section Switch to CMake for better compatibility with other prijects Backport upstream commit 7cabadd9035013816dfbc951c74cf3f2709c1489 References: https://github.com/anrieff/libcpuid/commit/7cabadd9035013816dfbc951c74cf3f2709c1489 Compile tested on FreeBSD 13.1-STABLE (amd64) (make, make test, make check-plist) Poudriere testport OK 12.3-RELEASE (amd64) Poudriere testport OK 13.1-RELEASE (i386)
> Use upstream release archive as recommended by Porters Handbook USE_GITHUB > section Are we winning anything this way? Distfile name is indeed more clear, but it weighs twice as much: -SIZE (anrieff-libcpuid-v0.6.0_GH0.tar.gz) = 240709 +SIZE (libcpuid-0.6.0.tar.gz) = 554265 OTOH this might be because it's bootstrapped, so autoreconf is not required, I'll look into this. > Switch to CMake for better compatibility with other projects IMHO GNU autotools should be always preferred to CMake as the latter pulls more dependencies. Exactly what kind of compatibility we're seeking in this case? > Backport upstream commit 7cabadd9035013816dfbc951c74cf3f2709c1489 They've just released v0.6.1, I suppose it should be part of it already.
The main benefit is that we get a static release archive as supposed to a generated on the fly by GitHub. The extra size is because ./configure and friends are packaged which is nice. You're correct that 7cabadd9035013816dfbc951c74cf3f2709c1489 is included in 0.6.1. CMake offers .cmake files in addition to .pc, the dependency is argument itself is getting old. You will most likely use it on most installs one way or another and if we adopted and/or meson more we'd would likely reduce the overall compile time for many setups in the end given how much time we spend in ./configure scripts and the fact that gmake/make doesn't scale all that well. Anyhow, feel free to stick with Autotools if you want, it was just a suggestion.
(In reply to Daniel Engberg from comment #2) > The main benefit is that we get a static release archive as [opposed] to > a generated on the fly by GitHub. Right, static distfiles are also served with correct modification time which I particularly like. > The extra size is because ./configure and friends are packaged Yes, as expected. I believe a few hundred bytes is acceptable price to pay for convenience in this case. > CMake offers .cmake files in addition to .pc, the dependency is argument > itself is getting old. You will most likely use it on most installs one way > or another While it is true that CMake is likely to be already installed on the ports user's system, dependency argument is mostly about building in pristine environment as described in e.g. commit 57dd5abd6018 of the `textproc/libxml2' (you'd probably remember).
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=ff7949343c4aeacc08afac2ff66d90c372c78584 commit ff7949343c4aeacc08afac2ff66d90c372c78584 Author: Alexey Dokuchaev <danfe@FreeBSD.org> AuthorDate: 2022-10-30 04:04:40 +0000 Commit: Alexey Dokuchaev <danfe@FreeBSD.org> CommitDate: 2022-10-30 04:04:40 +0000 sysutils/libcpuid: update to version 0.6.1, use upstream release archive While few hundreds bytes larger, distfile is more cache-friendly (mtime remains constant unlike for tarballs generated on the fly by GitHub) and comes properly bootstrapped, allowing to drop `autoreconf' item from the USES list. Remove ONLY_FOR_ARCHS limitation: while currently support is limited for x86 CPUs, it builds everywhere and gracefully handles unknown ones, thus unbreaking more of those reverse dependencies mentioned in 9482644374c1. PR: 267277 (partially applied) sysutils/libcpuid/Makefile | 13 ++++--------- sysutils/libcpuid/distinfo | 6 +++--- sysutils/libcpuid/pkg-plist | 2 +- 3 files changed, 8 insertions(+), 13 deletions(-)
Committed, thanks (I've sticked to GNU autotools for now, but that might change one day).