The VS2019 Bridge Release

Adds a manual VS2019 (msvc 192) build track, so a library can be built and published for Visual Studio 2019 under a Conan 2 client. This is the bridge that lets a downstream product move conan1 → conan2 and VS2019 → VS2022 as two separate steps instead of one simultaneous jump.

Nothing here changes what CI builds or publishes. Every non-msvc-192 toolchain resolves the same graph it resolved in 2.17.0.

What changed

1. xmsconan vs2019 — the driver

New xmsconan/build_tools/vs2019_build.py and an xmsconan_vs2019 console script, with three subcommands:

• setup — add and log in to the aquaveo-vs2019 remote, then preflight.
• build — build the VS2019 matrix. --preview prints the configuration table and exits.
• upload — push built msvc 192 packages to aquaveo-vs2019.

Preflight gates the run on the three things that actually break it: a discoverable VS2019 toolset, a conan client, and a configured remote. Each failure line names its own fix. Nothing builds until all three pass.

2. Recipe fork on msvc 192

XmsConan2File._is_vs2019() auto-detects compiler == msvc and compiler.version == 192. There is no profile option and no downstream opt-in — a library gets the fork by virtue of the toolchain it is being built for.

Two new class attributes drive it:

• vs2019_requirements replaces default_requirements on that toolchain — it does not extend it. Same package set, different versions: boost/1.74.0.3 + zlib/1.2.11 (the legacy stack the desktop products link against) versus boost/1.86.0 + zlib/1.3.1 everywhere else. zlib is required on both: the generated CMakeLists.txt calls find_package(ZLIB REQUIRED) unconditionally and sources such as xmscore/dataio/daStreamIo.cpp include <zlib.h>. The Conan 1 recipe got away with omitting it only because its CMake integration exposed every dependency's include directories globally; under CMakeDeps a package must declare what it uses.
• vs2019_dependency_overrides retargets XMS dependencies whose 6.x line the legacy products still pin — {"xmscore": "xmscore/[>=6.0.1 <7.0.0]"}. An override may change only the version, never the package name, and its key must match a declared xms_dependencies entry; _validate_vs2019_dependency_overrides enforces both. configure() and run_python_tests() iterate the unresolved xms_dependencies, so a rename would set options on — and pip-install from — a package no longer in the graph.

pybind11 stays at 3.0.1 on VS2019 too, an intentional upgrade from the Conan-1-era 2.9.1.

3. Packager: windows_vs2019 configuration set and remote-aware upload

A windows_vs2019 entry alongside windows / linux / darwin, pinning compiler.version to msvc 192 across Release/Debug × dynamic/static runtime. upload() gained a remote parameter — it previously hardcoded -r aquaveo, which is exactly the line that would have published msvc 192 binaries onto the stable remote.

4. constants.py

Remote names and URLs were duplicated across modules; a remote rename was a grep-and-hope. They now live in one place.

One deliberate exception, documented in the module docstring: xms_conan2_file.py does not import from it. build_file_generator.copy_xms_conan2_file() copies that file next to each library's generated conanfile.py, where it is imported as a top-level module with no xmsconan package around it, so it has to stay standalone and repeat the msvc 192 literal.

5. Generated-output changes — narrow by design

• conanfile.py.jinja emits a vs2019_dependency_overrides attribute only when build.toml declares a [vs2019_dependency_overrides] table. A repo without one regenerates byte-identical.
• build.py.jinja now exits 1 when builder.upload() reports errors, instead of printing and returning success.

Why this doesn't move anything on aquaveo-stable

requirements() was refactored from inline self.requires("boost/1.86.0") / self.requires("zlib/1.3.1") calls into an iteration over default_requirements, which holds those same two references in the same order. On any toolchain that is not msvc 192 the resulting graph is identical to 2.17.0's.

Verified after release by installing xmsconan==2.18.0 from devpi into a clean venv: default_requirements == ['boost/1.86.0', 'zlib/1.3.1'], vs2019_requirements == ['boost/1.74.0.3', 'zlib/1.2.11'], all eight VS2019 profiles present in the wheel, xmsconan_vs2019 on PATH.

Scope

This track is manual and temporary.

Manual: it runs from a developer workstation, not CI. GitHub retired the windows-2019 runner, so there is no hosted image with the v142 toolset to schedule this on. It also requires one invocation per Python version, from a virtualenv of that version — the recipe calls find_package(Python3 ${PYTHON_TARGET_VERSION} EXACT REQUIRED) and CMake will not find an interpreter that is not installed.

Temporary: aquaveo-vs2019 exists so consumers can change one variable at a time. When the last one clears VS2022, this track and the remote both go away.