chore(meos): bump pinned MEOS to the 1.4-integration SHA (unblocks *_port_core stack)#164
Open
estebanzimanyi wants to merge 3 commits into
Open
Conversation
Switches `vcpkg_ports/meos/portfile.cmake` REF from the pre-bump
`f11b7443e` (MobilityDB#768) to the user-fork integration branch
`estebanzimanyi/MobilityDB:integration/meos-1.4-bump` at commit
`80c24f46d`, which merges all 15 open MEOS-1.4 bump PRs into one
buildable commit:
* #1075 portable bare-name aliases * #1090 geog_in fall-through fix
* #1081 tcbuffer accessors * #1094 tolerance fix (0.0)
* #1082 tnpoint accessors * #1095 meos_error contract doc
* #1083 tcbuffer/tpose ctors * #1096 meos_error CI ratchet
* #1084 from_base time ctors * #1097 per-site fall-through fixes
* #1085 tpose_from_mfjson * #1098 math/aggfuncs/datagen fixes
* #1088 geodetic spatialrels * #1100 ea_* geodetic completion
* #1101 signature uniformization
Both libmeos and libMobilityDB-1.4 built green from this SHA
(Linux x86_64). Switches the pin **back to MobilityDB/MobilityDB**
once the 15 PRs land on master — that's a one-line edit (REPO
+ REF + SHA512); no other code change.
Why this is the right move now: the bump's source-of-truth IS the
15 open green PRs — pinning to their integration SHA lets every
downstream consumer pick up the new MEOS surface today, without
waiting on the review-merge cascade. Unblocks specifically:
* The `*_port_core` stack (MobilityDB#148 / MobilityDB#150 / MobilityDB#151 / MobilityDB#153 / MobilityDB#155 / MobilityDB#156)
which needs the `tcbuffer*` / `tnpoint*` / `tpose*` symbols
exported by #1081–#1085 (currently 0/0/0 in the pre-bump pin).
* The TRTREE / MEST work (MobilityDB#143 / MobilityDB#144) which composes with the
uniformized array-return signatures from #1101.
* The geodetic correctness story (the 3 preview releases) which
consumes #1088 / #1090 / #1094 / #1100 ea_* completion.
Also updates the runtime version stamp `MOBILITYDUCK_MEOS_PIN` in
`src/mobilityduck_extension.cpp` so `SELECT mobilityduck_full_version()`
reports the new pin.
Refs: MobilityDB #1075, #1081-1085, #1088, #1090, #1094, #1095-1098,
#1100, #1101 (the 15 open bump PRs).
The stage_icu helper mapped only the Linux uname values, so on the macOS arm64 test runner uname -m returned "arm64" and the icu extension was copied to .duckdb/extensions/v1.4.4/arm64 instead of .../osx_arm64, where DuckDB's autoload looks. The hub fallback is not reliably resolvable on that runner, so the osx_arm64 Test step failed to load the extension. Map the OS and architecture to the DuckDB platform string (linux_amd64, linux_arm64, osx_amd64, osx_arm64) so the locally built icu is staged at the path autoload expects on every tested platform; the Linux mapping is unchanged. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
`meosType` (lower-case) is the **pre-consolidation** MEOS type name; `MeosType` (upper-case) is the **post-consolidation** target that the upstream rename sweep has not yet reached. The current vcpkg pin (`vcpkg_ports/meos/portfile.cmake` REF f11b7443ee98…) is still pre-consolidation: `meos/include/temporal/meos_catalog.h` line 121 declares the typedef as `} meosType;` and every MEOS API uses the lower-case spelling. MobilityDuck's source code consistently uses `meosType` to match — `grep -rn '\bMeosType\b' src/` finds the name only on the alias line and its comment, nowhere else. c8cad6d added `using meosType = MeosType;` as a forward-looking bridge for the eventual consolidation bump. That bridge points at `MeosType`, which the current pin does NOT yet expose, so it breaks every PR's Linux arm64 build with: /duckdb_build_dir/src/include/tydef.hpp:18:18: error: ‘MeosType’ does not name a type; did you mean ‘meosType’? The fix is to drop the premature alias and replace the misleading comment with one that documents the pre/post-consolidation distinction and the resume path for the next pin bump — at that point a reviewer can either restore the bridge (this time it'll be valid because `MeosType` will exist) or sweep the MobilityDuck source from `meosType` to `MeosType` in a single PR. Unblocks every in-flight PR's Linux arm64 build: MobilityDB#126, MobilityDB#130, MobilityDB#149, MobilityDB#158, MobilityDB#159, MobilityDB#160, plus the entire `feat/*_port_core` extended-type stack (MobilityDB#148/MobilityDB#150/MobilityDB#151/MobilityDB#153/MobilityDB#155/MobilityDB#156).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Switches the vcpkg MEOS pin from the pre-bump
f11b7443eto the user-fork integration branchestebanzimanyi/MobilityDB:integration/meos-1.4-bumpat commit80c24f46d, which merges all 15 open MEOS-1.4 bump PRs into one buildable commit.What's in the integration SHA
All 15 merged cleanly into one branch on the user's fork. Both
libmeosandlibMobilityDB-1.4built green from80c24f46d(Linux x86_64).Why this is the right move now
The MEOS-1.4 bump's source-of-truth is the 15 open green PRs. Pinning to their integration SHA lets every downstream consumer pick up the new MEOS surface today, instead of waiting on the review-merge cascade. Specifically unblocks:
*_port_corestack (Add the core tcbuffer type port #148 / Add the core tnpoint type port #150 / Add the core tpose type port #151 / Add the core trgeometry type port #153 / Add the core tpcpoint type port #155 / Add the core tpcpatch type port #156) — needs thetcbuffer*/tnpoint*/tpose*symbols exported by #1081-#1085. The earlier symbol-gap analysis on each PR showed 0 such symbols in the pre-bump pin; all 105+ are present in this pin.countout-param pattern).Reverting once the bump lands on master
One-line edit:
vcpkg_from_github( OUT_SOURCE_PATH SOURCE_PATH - REPO estebanzimanyi/MobilityDB - REF 80c24f46d042baa2613515b0f5b82255f21fb522 - SHA512 c21d978270bcd2e996506bc692abd3c3a8e57f31032443e07107cdc25ac8b7ebed7df42f71ad8b740e732ea35317524d3b14089277038efabb774a2dd53c0b23 + REPO MobilityDB/MobilityDB + REF <master tip after #1075/#1081-1085/#1088/#1090/#1094/#1095-1098/#1100/#1101 merge> + SHA512 <regenerated by vcpkg install> )No other change required — the on-disk source layout is identical between the fork and master once the 15 PRs land.
Risk
Zero behaviour change relative to the bump's intent — the integration is just merge-commits between the 15 PRs, no source edits. Local build of MobilityDuck pulls these 15 PRs' MEOS surface verbatim.
Refs
MobilityDB#1075, MobilityDB#1081–#1085, MobilityDB#1088, MobilityDB#1090, MobilityDB#1094, MobilityDB#1095–#1098, MobilityDB#1100, MobilityDB#1101 — the 15 open bump PRs.