search

conda-forge / vc-feedstock

A conda-smithy repository for vc.
BSD 3-Clause "New" or "Revised" License
4 stars 22 forks source link

BUG: builds for non-latest minor versions broken? use vsdownload.py utility? #57

Closed h-vetinari closed 1 year ago

h-vetinari commented 1 year ago

While working on an unrelated change in #56, CI started failing with 

C:\Program Files\Microsoft Visual Studio\2022\Enterprise>CALL "VC\Auxiliary\Build\vcvars64.bat" -vcvars_ver=14.28 10.0.22621.0 
**********************************************************************
** Visual Studio 2022 Developer Command Prompt v17.5.4
** Copyright (c) 2022 Microsoft Corporation
**********************************************************************
[ERROR:vcvars.bat] Toolset directory for version '14.28' was not found.
[ERROR:VsDevCmd.bat] *** VsDevCmd.bat encountered errors. Environment may be incomplete and/or incorrect. ***
[ERROR:VsDevCmd.bat] In an uninitialized command prompt, please 'set VSCMD_DEBUG=[value]' and then re-run
[ERROR:VsDevCmd.bat] vsdevcmd.bat [args] for additional details.
[ERROR:VsDevCmd.bat] Where [value] is:
[ERROR:VsDevCmd.bat]    1 : basic debug logging
[ERROR:VsDevCmd.bat]    2 : detailed debug logging
[ERROR:VsDevCmd.bat]    3 : trace level logging. Redirection of output to a file when using this level is recommended.
[ERROR:VsDevCmd.bat] Example: set VSCMD_DEBUG=3
[ERROR:VsDevCmd.bat]          vsdevcmd.bat > vsdevcmd.trace.txt 2>&1
Tests failed for vs2019_win-64-19.28.29325-hed2d97d_11.conda - moving package to D:\bld\broken

As it turns out, this was pre-existing (see e.g. CII of another PR, resp. also for the last merge to main), it just didn't fail the build.

At first I thought this had something to do with the new artefact naming as of vs2022, i.e.

Microsoft.VisualStudio.Component.VC.14.29.16.11.x86.x64     # as of vs2022
# equivalent to
Microsoft.VisualStudio.ComponentGroup.VC.Tools.142.x86.x64  # as of vs2022
# compared to
Microsoft.VisualStudio.Component.VC.v141.x86.x64            # until vs2019

However, vswhere.exe only searches for a given artefact, and returns nothing if it doesn't find it. In particular, we're trying to build for 14.28.16.8 & 14.32.17.2 here, but both fail in #56 as not being found. I tried to correct the vswhere component names, but the larger issue is that AFAICT our repack script points to unversioned vcRuntimeMinimum_amd64 artefacts, which will presumably come with the latest minor version (i.e. 16.11 instead of 16.8).

Having worked on exactly these components in https://github.com/conda-forge/clang-win-activation-feedstock/pull/18 recently, I'm wondering why we don't use vsdownload.py from https://github.com/mstorsjo/msvc-wine - that way we could ensure that the right artefacts are installed with more control (the older artefacts still exist, they just have to be explicitly requested), and could ensure that everything is present as desired.

Since I don't know the history of vc_repack.py here, I wanted to open this issue first to find out if this is desirable. It took a while to get right for clang-win, so don't want to waste that effort for nothing.

isuruf commented 1 year ago

I tried to correct the vswhere component names, but the larger issue is that AFAICT our repack script points to unversioned vcRuntimeMinimum_amd64 artefacts, which will presumably come with the latest minor version (i.e. 16.11 instead of 16.8).

How did you come to this conclusion?

h-vetinari commented 1 year ago

I don't see where we're selecting an artefact except by installing vcRuntimeMinimum_amd64. AFAICT, there's no way to select we're selecting 14.28 artefacts upon downloading, and so vswhere will not find them. I don't know why the activation scripts decided to start failing in #56, but looking closer, I believe we're not installing the non-latest minor versions correctly here.

At least the experience on the clang-win-activation was different, where we actually downloaded the specific minor versions that are specified in the cbc.

h-vetinari commented 1 year ago

Non-latest minor versions are only for users. Also:

@h-vetinari: Hm, perhaps the difference I wasn't seeing is the libs vs. toolchain issue, where we can redistribute the libs, but not the toolchain, so we need to match what's in the images, and that the toolset minor version isn't actually relevant as it's only about the cl-version anyway.

Thanks for the explanations Isuru. Closing