Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bump build tools version to v14.41 #83

Closed
1 task done
mgovers opened this issue Sep 3, 2024 · 5 comments · Fixed by #85
Closed
1 task done

Bump build tools version to v14.41 #83

mgovers opened this issue Sep 3, 2024 · 5 comments · Fixed by #85
Labels

Comments

@mgovers
Copy link
Contributor

mgovers commented Sep 3, 2024

Solution to issue cannot be found in the documentation.

  • I checked 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
Copy link
Member

Noting a workaround from conda-forge/admin-requests#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
Copy link
Member

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
Copy link
Contributor Author

mgovers commented Sep 10, 2024

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
Copy link
Member

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 (actions/runner-images#10448 (comment), actions/runner-images#10490 (comment))

@jdblischak
Copy link
Member

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 #82 (comment). 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.

@isuruf isuruf mentioned this issue Sep 10, 2024
5 tasks
@github-staff github-staff deleted a comment from maher-nakesh Oct 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants