fix(build.mcpp,ci): one deployment target for every host compile; restore xlings in the no-VS job

macOS rejected `import std;` together with `import mcpp;`: mcpp.pcm had been
built at the host default (15.0) while the compile consuming it now carried
14.0. Putting the flag on the std path alone just moved the mismatch to the
other module — clang refuses either direction.

The deployment target now lives in host_base_flags, which feeds every compile
in this file: the bundled mcpp module's precompile, its object step, and the
build.mcpp compile. One resolution, one place, and the same value goes to
stdmod so the std BMI agrees too.

The bare-Windows job also needs xlings back — masking Visual Studio worked
(the postcondition and e2e 182's own self-check both confirm it), but dropping
the build step took bootstrap-mcpp with it, so mcpp had no backend to install
the winlibs toolchain through. It runs after masking, where nothing it does
can hold Visual Studio open.

Author: Sunrisepeak

.github/workflows/ci-windows.yml

@@ -206,6 +206,12 @@ jobs:
           }
           Write-Host "Visual Studio masked: no VC\Tools\MSVC remains."
 
+      # After masking, so nothing this action does can be holding Visual
+      # Studio open. It installs xlings (which mcpp resolves the winlibs
+      # toolchain through) and a released mcpp; neither needs a C++ compiler,
+      # so a masked VS is irrelevant to it.
+      - uses: ./.github/actions/bootstrap-mcpp
+
       - name: "No Visual Studio: fallback to winlibs GCC (e2e 182)"
         shell: bash
         env:

src/build/build_program.cppm

@@ -184,9 +184,24 @@ std::string env_value(const std::string& name) {
 // --target, prepare.cppm resolves the spec a second time without the target axis
 // (host_tc_for_build_program) and passes that here, so the native cases are the
 // only ones needed. Passed as separate argv tokens (no shell).
-std::vector<std::string> host_base_flags(const mcpp::toolchain::Toolchain& tc) {
+std::vector<std::string> host_base_flags(const mcpp::toolchain::Toolchain& tc,
+                                         std::string_view macosDeploymentTarget) {
     std::vector<std::string> f;
 
+    // macOS deployment target, FIRST and unconditionally, because clang
+    // refuses to load a module built for a different one and this function's
+    // result feeds every compile in this file: the bundled `mcpp` module's
+    // precompile, its object step, and the build.mcpp compile itself. Putting
+    // it anywhere narrower produced the mismatch in whichever direction was
+    // left out — first the std BMI (built for 14.0) against a compile with no
+    // version-min, then mcpp.pcm (built at the host default 15.0) against a
+    // compile that had just been given 14.0.
+    if constexpr (mcpp::platform::is_macos) {
+        if (!macosDeploymentTarget.empty())
+            f.push_back(std::string("-mmacosx-version-min=")
+                        + std::string(macosDeploymentTarget));
+    }
+
     // MSVC carries none of this on the command line: cl.exe and link.exe find
     // headers and import libraries through INCLUDE / LIB, which detection
     // synthesized into tc.envOverrides. Emitting the GNU shapes below would
@@ -712,7 +727,13 @@ std::expected<void, std::string> run_build_program(
         tc, cppStandard.canonical.empty() ? std::string_view("c++23")
                                           : std::string_view(cppStandard.canonical),
         cppStandard.level);
-    auto base = host_base_flags(tc);
+    // One resolution of the deployment target, used by every compile below
+    // and by the std module it asks stdmod to build — they must agree or
+    // clang rejects the BMI.
+    const std::string macosDeploymentTarget =
+        mcpp::platform::macos::deployment_target(
+            m.buildConfig.macosDeploymentTarget);
+    auto base = host_base_flags(tc, macosDeploymentTarget);
 
     // The host compile has always been spelled in GNU driver syntax with no
     // dialect branch at all — `grep -i msvc` over this file used to hit only
@@ -781,9 +802,6 @@ std::expected<void, std::string> run_build_program(
                 "       Use #include in build.mcpp, or switch to a toolchain "
                 "that provides one.", tc.label()));
         }
-        const std::string macosDeploymentTarget =
-            mcpp::platform::macos::deployment_target(
-                m.buildConfig.macosDeploymentTarget);
         auto sm = mcpp::toolchain::ensure_built(
             tc, cppStandard.canonical, std_flag, macosDeploymentTarget);
         if (!sm) {
@@ -792,19 +810,6 @@ std::expected<void, std::string> run_build_program(
                 "built for the host toolchain: {}", sm.error().message));
         }
 
-        // The std BMI was built FOR a deployment target, and clang refuses to
-        // load a module built for a different one ("compiled for the target
-        // 'arm64-apple-macosx14.0.0' but the current translation unit is
-        // being compiled for …"). The main build makes the value explicit on
-        // every TU for exactly this reason (flags.cppm); the build.mcpp
-        // compile has to say the same thing or the BMI it just asked for is
-        // rejected. host_base_flags contributes nothing here — on macOS it
-        // trusts the clang cfg and returns empty.
-        if constexpr (mcpp::platform::is_macos) {
-            if (!macosDeploymentTarget.empty())
-                stdFlags.push_back("-mmacosx-version-min=" + macosDeploymentTarget);
-        }
-
         auto traits = mcpp::toolchain::bmi_traits(tc);
         if (traits.stdBmiUsePrefix.empty()) {
             // GCC: BMIs are found implicitly under <cwd>/gcm.cache, so stage