search

conda-forge / vc-feedstock

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

Bump build tools version to v14.41 #83

Closed mgovers closed 2 months ago

mgovers commented 2 months ago

Solution to issue cannot be found in the documentation.

Issue

Like in #73 (workaround in #76), the build tools version listed in the feedstock are (again) out of date compared to the version installed in the container. NOTE: #82 most likely attempted the same thing, but maybe failed cfr. this comment

C:\Program Files\Microsoft Visual Studio\2022\Enterprise>CALL "VC\Auxiliary\Build\vcvars64.bat" -vcvars_ver=14.41 10.0.22621.0 
**********************************************************************
** Visual Studio 2022 Developer Command Prompt v17.10.5
** Copyright (c) 2022 Microsoft Corporation
**********************************************************************
[ERROR:vcvars.bat] Toolset directory for version '14.41' 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

This sounds like something that can be automated. #56 did not fix it.

Installed packages

bzip2:           1.0.8-h2466b09_7           conda-forge
    ca-certificates: 2024.8.30-h56e8100_0       conda-forge
    libffi:          3.4.2-h8ffe710_5           conda-forge
    libsqlite:       3.46.0-h2466b09_0          conda-forge
    libzlib:         1.3.1-h2466b09_1           conda-forge
    openssl:         3.3.1-h2466b09_3           conda-forge
    pip:             24.2-pyh8b19718_1          conda-forge
    python:          3.10.14-h4de0772_0_cpython conda-forge
    setuptools:      72.2.0-pyhd8ed1ab_0        conda-forge
    tk:              8.6.13-h5226925_1          conda-forge
    tzdata:          2024a-h8827d51_1           conda-forge
    ucrt:            10.0.22621.0-h57928b3_0    conda-forge
    vc:              14.3-h8a93ad2_20           conda-forge
    vc14_runtime:    14.40.33810-hcc2c482_20    conda-forge
    vs2015_runtime:  14.40.33810-h3bf8584_20    conda-forge
    wheel:           0.44.0-pyhd8ed1ab_0        conda-forge
    xz:              5.2.6-h8d14728_0           conda-forge
    vs_win-64:        2022.11-h72b6792_20     conda-forge
    vswhere:          3.1.7-h57928b3_0        conda-forge
    xz:               5.2.6-h8d14728_0        conda-forge
    zstd:             1.5.6-h0ea2cb4_0        conda-forge

Environment info

active environment : base
    active env location : C:\Miniforge
            shell level : 1
       user config file : C:\Users\VssAdministrator\.condarc
 populated config files : C:\Miniforge\.condarc
                          C:\Users\VssAdministrator\.condarc
          conda version : 24.3.0
    conda-build version : 24.7.1
         python version : 3.10.14.final.0
                 solver : libmamba (default)
       virtual packages : __archspec=1=x86_64_v4
                          __conda=24.3.0=0
                          __win=0=0
       base environment : C:\Miniforge  (writable)
      conda av data dir : C:\Miniforge\etc\conda
  conda av metadata url : None
           channel URLs : https://conda.anaconda.org/conda-forge/win-64
                          https://conda.anaconda.org/conda-forge/noarch
             user-agent : conda/24.3.0 requests/2.31.0 CPython/3.10.14 Windows/10 Windows/10.0.20348 solver/libmamba conda-libmamba-solver/24.1.0 libmambapy/1.5.8
          administrator : True
             netrc file : None
           offline mode : False
h-vetinari commented 2 months ago

Noting a workaround from https://github.com/conda-forge/admin-requests/pull/1062 for reference:

c_compiler:             # [win]
  - vs2022              # [win]
c_compiler_version:     # [win]
  - 19.40               # [win]
cxx_compiler:           # [win]
  - vs2022              # [win]
cxx_compiler_version:   # [win]
  - 19.40               # [win]
h-vetinari commented 2 months ago

The annoying thing is that azure pipelines still has agents with both 17.10 and 17.11 in operation, and it depends on chance which one you get. I cannot yet say which one is more common, but it's generally "solvable" with a couple restarts.

mgovers commented 2 months ago

The annoying thing is that azure pipelines still has agents with both 17.10 and 17.11 in operation, and it depends on chance which one you get. I cannot yet say which one is more common, but it's generally "solvable" with a couple restarts.

thanks for your input. It's indeed annoying that it works that way. IMO, there should be a way to "just" obtain the correct VC and VC build tools versions directly from the environment set by Visual Studio. That said, I still am not convinced that the way Microsoft decided to set and handle the environment can be considered good in the first place, but there's not much we can do there, unfortunately.

jdblischak commented 2 months ago

The annoying thing is that azure pipelines still has agents with both 17.10 and 17.11 in operation, and it depends on chance which one you get. I cannot yet say which one is more common, but it's generally "solvable" with a couple restarts.

This has been unbelievably frustrating. There is no way to pin an image version for more stability, and the Azure team does not communicate their deployment plans to developers.

I've been pleading with the Azure developers to better communicate with us, to very little effect (https://github.com/actions/runner-images/issues/10448#issuecomment-2338301212, https://github.com/actions/runner-images/pull/10490#issuecomment-2318463571)

jdblischak commented 2 months ago

IMO, there should be a way to "just" obtain the correct VC and VC build tools versions directly from the environment set by Visual Studio.

This sounds similar to what I was asking about in https://github.com/conda-forge/vc-feedstock/pull/82#issuecomment-2315619084. Unfortunately AFAICT there is no way to make our feedstock builds more robust to the version of Visual Studio that is installed in the Azure Windows image.