Repository navigation
vcpkg release prep for v0.8.1: #173 Step 2, stale overrides, and a pass over the port automation #408
Description
Activity
Worked each item. The release is unblocked; the port work is not.
Pre-release: one blocker, fixed and landed
make distnever shippedCMakeLists.txt,cmake/warn-stale-installs.cmake.inorinclude/ta_config.h.cmake, sota-lib-<ver>-src.tar.gzwas an autotools-only distribution. That is fine while the port builds the GitHub tag archive, and it is a broken port the day it builds the release asset instead, which is item 1 below. Asset content is fixed at release time, so this had to land before publishing.Fixed in
327228b41(CMAKE_FILESinMakefile.amEXTRA_DIST). Verified against the real 0.8.1 tarball:- every one of the 341 source-tree paths
CMakeLists.txtreads is present. That sweep is a file-existence check rather than a compile, so it covers the Windows and macOS triplets too. - a default
cmakeconfigure and build produces ata_regtestthat reports* All tests succeeded. * - the port-shaped build,
-DBUILD_DEV_TOOLS=OFF, installs a layout a consumer compiles and links against
-DBUILD_BENCHMARKS=ONstill fails from the tarball, consistent with that option being documented as developers-only.Nothing gates this.
test_autotool_srcbuilds the extracted tarball with autotools only, so a futurecmake/*.inadded without a line inEXTRA_DISTfails only at the next port update.Item 1: #173 step 2
Due at this release, and the reason is sharper than "the next release". The tag archive's pax header carries the commit SHA; verified on the v0.7.1 archive,
comment=2247d599bddf37ed37e3a709371517e46efc66f6. Step 3 rewrites history at and below v0.7.1, which moves v0.7.1's SHA and every descendant's, including whatever commit v0.8.1 gets tagged at. Leaving the port on a tag archive means step 3 breaks 0.8.1 itself, not only the archaeology.Two changes that must land together:
- portfile:
vcpkg_from_githubtovcpkg_download_distfile+vcpkg_extract_source_archiveagainstreleases/download/v0.8.1/ta-lib-0.8.1-src.tar.gz. PassSOURCE_BASE "${VERSION}"explicitly, because CMake's default STEM ofta-lib-0.8.1-src.tar.gzsplits at the first dot and yieldsta-lib-0. read_latest_release_src_tarball(): hash the release asset. Its docstring warns against exactly this, and the warning is the mirror image of the fix rather than a veto. The 0.7.1 mismatch happened because the port fetched the tag archive while the script hashed the asset; flipping either one alone reproduces it exactly.
Asset immutability is not a risk:
release-step-1hard-fails against an already-published release, so the assets are frozen once step 2 flips the draft.Item 2: stale overrides
Both port patches are dead. Applied against the 0.8.1 tree:
fix-forced-install-prefix.patch -> error: patch does not apply no-system-cleanup.patch -> Reversed (or previously applied) patch detectedCMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULTand the warn-over-delete replacement forcleanup_glob.cmakeare both upstream now.post-release-vcpkg.pyrewrites only the version and the first SHA512, so it leaves thePATCHESblock and the port build fails. Deleting them is also a literal PR-template checkbox: "All patch files in the port are applied and succeed".Item 3: a pass over the port automation
New in 0.8.1 and not faced by the 0.7.1 port: the CMake build installs
ta-lib.pcunderif(UNIX), where v0.7.1'sCMakeLists.txtinstalled none. vcpkg-tool'spostbuildlint.cppscans.pcfiles for the packages directory and returnsPROBLEM_DETECTEDwith a note pointing atvcpkg_fixup_pkgconfig(). vcpkg CI runs x64-linux, arm64-linux and arm64-osx, so it fails on the main triplets rather than a corner. All seven numerical ports surveyed for comparison (fftw3, gsl, openblas, cminpack, nlopt, arpack-ng) call it.The SONAME change (
0:0:0to2:0:1) and the reduced export set need no port change. The globs still match, Windows is static-only, and the static target's hidden visibility still re-exports theTA_LIB_APIsurface.The script itself: the version and SHA512 rewrite,
x-add-version, and the fork/push/PR path were all exercised on the 0.7.1 PR and work. Never run: thepost-release-vcpkg.ymlworkflow (0 runs, since it fires onrelease: publishedand 0.7.1 predates it),create_monitor_issue, and the reconcile path. 0.8.1 is their first live exercise.What is left, all after the release
- switch the portfile to
vcpkg_download_distfile(Housekeeping: remove the old dist/ binaries from git history (3 steps, spread over ~2 releases) #173 step 2) - flip
read_latest_release_src_tarball()to hash the release asset, in the same change - delete
fix-forced-install-prefix.patchandno-system-cleanup.patch - add
vcpkg_fixup_pkgconfig() - verify with a local
./vcpkg install talibbefore pushing
Green triplet CI is not the signal for any of these: every check passed on the first commit of microsoft/vcpkg#52719 and review still sent it back twice across ten days.
Not blocking, and worth its own issue rather than this one: ta-lib installs no CMake package config, so the port carries a hand-written
vcpkg-cmake-wrapper.cmake. Six of the seven peers useinstall(EXPORT)plusvcpkg_cmake_config_fixup()instead; gsl is the other holdout. Doing it would also give every non-vcpkg consumer a plainfind_package(ta-lib CONFIG).- every one of the 341 source-tree paths
vcpkg port update for 0.8.1 is open as a draft: microsoft/vcpkg#53896
It covers the post-release items above: the port now downloads the release asset, both patches are gone,
vcpkg_fixup_pkgconfig()is added, and it builds only the requested linkage. Two wrapper fixes rode along:talib::talibnow linksmon Linux, and links the library whenCMAKE_BUILD_TYPEis empty or custom.It stays a draft until CI is green and the per-triplet file lists show talib was actually built on the Windows and macOS triplets. This issue closes when the PR merges.
Merged: microsoft/vcpkg#53896 (vicroms, 2026-09-16).
vcpkg install talibfrom current vcpkg master builds 0.8.1 fromta-lib-0.8.1-src.tar.gz, and the baseline is 0.8.1.All items are done: the portfile downloads the release asset (#173 step 2, now ticked there),
post-release-vcpkg.pyhashes that asset, both patches are deleted,vcpkg_fixup_pkgconfig()is added, and the port builds only the requested linkage. Review added two more: Windows is no longer static-only (dynamic triplets installta-lib.dll, its import library and PDBs), andtalib::talibnow carriesmon Linux, links in every build type, and accepts both<ta_libc.h>and<ta-lib/ta_libc.h>.Two items carry to the next port update, at 0.8.2:
- Guard the
ta-lib-static.librename withNOT VCPKG_TARGET_IS_MINGW. MinGW buildslibta-lib-static.a, sofile(RENAME)would hard-fail there. - Decide whether
supportsshould exclude MinGW, which cannot configure upstream CMake without a vcvarsall environment.
The hand-written
vcpkg-cmake-wrapper.cmakegoes away once TA-Lib installs its own CMake package config: #422.- Guard the
Decided for the 0.8.2 port update, so nothing is left tracking here: guard the
ta-lib-static.librename withNOT VCPKG_TARGET_IS_MINGWand buildx64-mingw-staticandx64-mingw-dynamicalongside the other triplets. 0.8.2 is the first release where MinGW can get past configure (the vcvarsallPlatformcheck is gone), so that run decidessupports: leave it as it is if they build, add!mingwin the same PR if they do not.Closing: the port is merged and live.
Umbrella for the vcpkg work that has to happen around the v0.8.1 release. Split out of #386's backlog and #173 so it has an owner; the items below are stated, not investigated — closing this means working each one out and bringing it to a conclusion.
1. #173 Step 2 — get the port off the GitHub tag archive
#173 Step 2 is scheduled for "the next release", and that is this one. It is the last blocker on #173 Step 3, which must not start until Step 2 has been live for two releases — so slipping it here costs two more release cycles.
The change is a microsoft/vcpkg PR switching
ports/talib/portfile.cmakefromvcpkg_from_githubtovcpkg_download_distfileagainst the release asset (releases/download/vX.Y.Z/ta-lib-X.Y.Z-src.tar.gz), which is what Homebrew already consumes.Ours has to move with it.
scripts/post-release-vcpkg.pycurrently computes its SHA512 over the tag archive, deliberately —read_latest_release_src_tarball()carries the reason in its docstring: hashing the release asset instead produced a hash mismatch on every triplet during the 0.7.1 PR. Switching the port and not the script (or the reverse) reproduces exactly that failure.2. Overrides carried over from the previous release
Whatever version overrides / pins were put in place for the last release need reviewing and removing where they are now stale. Not investigated here — part of what this issue is for.
3. A pass over the rest of the vcpkg path before release
scripts/post-release-vcpkg.pyand.github/workflows/post-release-vcpkg.ymlare the automation; they should be read once end to end against what 0.8.1 actually publishes, rather than assumed correct because 0.7.1 worked. 0.8.1 changes the SONAME (libta-lib.so.1) and the exported symbol set, neither of which the 0.7.1 port had to deal with.Sequencing
Step 2's PR lands against a published release asset, so it follows the release rather than gating it — but the port and
post-release-vcpkg.pymust agree before it is submitted, and #173 Step 3 waits on it.