Bump xmscore to 7.0.12 and regenerate CI with xmsconan 2.18.0 - #198
Merged
Conversation
Second library on the VS2019 bridge, after xmscore. Two coupled changes.
**xmscore 7.0.11 -> 7.0.12.** xms_dependencies pins an exact version, and
7.0.11 was never built for msvc 192 -- only 7.0.12 exists on aquaveo-vs2019.
Left at 7.0.11 the VS2019 build of xmsgrid fails at graph resolution before
compiling anything. 7.0.12 is published on both remotes at the same recipe
revision, so this bump is inert for the msvc 194 / gcc / clang builds: it is
the same source as 7.0.11, whose only commit was a CI regeneration.
**xmsconan 2.16.0 -> 2.18.0.** CI has to generate the recipe with the same
xmsconan the manual VS2019 track uses. XmsConan2File.export() copies
xms_conan2_file.py into the export folder, so its contents feed the recipe
revision hash, and 2.18.0 changes that file by 192 lines (the msvc 192 fork:
_is_vs2019, vs2019_requirements, vs2019_dependency_overrides). Generating with
2.16.0 in CI and 2.18.0 locally would publish different rrevs for the same
version, leaving aquaveo-stable and aquaveo-vs2019 out of step on what reads
as one release.
Nothing else in the generated output moves. build.toml declares no
[vs2019_dependency_overrides] table, so the generated conanfile.py gains no
new attribute. On any toolchain that is not msvc 192 the dependency graph is
unchanged: 2.18.0 refactored the inline self.requires("boost/1.86.0") /
self.requires("zlib/1.3.1") calls into an iteration over default_requirements
holding those same references in the same order.
The pins also stop being pins. 2.17.0 floated generated CI onto >= with
--upgrade, so this should be the last regeneration commit this repo needs. The
flake job picks up --upgrade here, which it lacked under the == pin.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.
Second library onto the VS2019 bridge, after xmscore (xmscore#130). Five lines, two coupled changes.
1. xmscore
7.0.11→7.0.12— required, not a routine bumpxms_dependenciespins an exact version, and 7.0.11 was never built for msvc 192. Only7.0.12exists onaquaveo-vs2019. Left at 7.0.11, the VS2019 build of xmsgrid fails at graph resolution before compiling a single file.This is inert for the VS2022 side: 7.0.12's only commit was a CI regeneration, so it is the same C++ source as 7.0.11, and it is published on both remotes at the same recipe revision
c58afa49b4625335e8fbaa650c925873.2. xmsconan
==2.16.0→>=2.18.0CI must generate the recipe with the same xmsconan the manual VS2019 track uses.
XmsConan2File.export()copiesxms_conan2_file.pyinto the export folder, so its contents feed the recipe revision hash. xmsconan 2.18.0 changes that file by 192 lines — the msvc 192 fork (_is_vs2019,vs2019_requirements,vs2019_dependency_overrides). Generating with 2.16.0 in CI and 2.18.0 locally would publish different rrevs for the same version, leavingaquaveo-stableandaquaveo-vs2019silently out of step.Blast radius on the VS2022 side: none
build.tomldeclares no[vs2019_dependency_overrides]table, so the generatedconanfile.pygains no new attribute.self.requires("boost/1.86.0")/self.requires("zlib/1.3.1")calls into an iteration overdefault_requirementsholding those same references in the same order.xms_dependencies = ["xmscore/7.0.12"],testing_framework = "cxxtest"(relevant becausegtest/1.17.0has no msvc 192 build).Last regeneration commit
2.17.0 floated generated CI from
==onto>=with--upgrade, so future xmsconan releases arrive on the next CI run rather than needing a commit here. The flake job picks up--upgrade, which it lacked under the==pin.🤖 Generated with Claude Code