Build scripts do not inherit environment from packit on Windows?

[mygizli04]

I'm trying to install make on Windows (arm64). I have a Developer Command Prompt that has the necessary environment to build make manually, but when running pit install the build script can't seem to be able to find the compiler.

Specifically, the build_w32.bat from make has the line call %COMPILER% >nul 2>&1 to check if the compiler is working, where %COMPILER% is set to cl.exe by default. It appears when packit calls the build script cl.exe is no longer in PATH, causing the build script to try and find it manually and since I have VS Build Tools instead of the IDE and the build script doesn't account for this it cannot find the compiler and fails.

Terminal session of me successfully compiling make from the same URL packit downloads, and with the same environment trying to install it with packit

C:\Users\sbeve\Downloads\make-4.4.1>build_w32 --without-guile

Creating GNU Make for Windows 9X/NT/2K/XP/Vista/7/8/10/11

- Building without Guile

Microsoft (R) C/C++ Optimizing Compiler Version 19.51.36252 for ARM64
Copyright (C) Microsoft Corporation.  All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

Compiling .\WinRel version
        1 file(s) copied.
        1 file(s) copied.
        1 file(s) copied.
- Compiling src/ar.c
ar.c
- Compiling src/arscan.c
arscan.c
- Compiling src/commands.c
commands.c
- Compiling src/default.c
default.c
- Compiling src/dir.c
dir.c
- Compiling src/expand.c
expand.c
- Compiling src/file.c
file.c
- Compiling src/function.c
function.c
src/function.c(1959): warning C4267: 'function': conversion from 'size_t' to 'unsigned int', possible loss of data
- Compiling src/getopt.c
getopt.c
- Compiling src/getopt1.c
getopt1.c
- Compiling src/guile.c
guile.c
- Compiling src/hash.c
hash.c
- Compiling src/implicit.c
implicit.c
- Compiling src/job.c
job.c
C:\Users\sbeve\Downloads\make-4.4.1\src\job.c(895) : warning C4701: potentially uninitialized local variable 'exit_sig' used
C:\Users\sbeve\Downloads\make-4.4.1\src\job.c(990) : warning C4701: potentially uninitialized local variable 'coredump' used
C:\Users\sbeve\Downloads\make-4.4.1\src\job.c(895) : warning C4701: potentially uninitialized local variable 'exit_code' used
- Compiling src/load.c
load.c
- Compiling src/loadapi.c
loadapi.c
- Compiling src/main.c
main.c
- Compiling src/misc.c
misc.c
src/misc.c(435): warning C4267: 'function': conversion from 'size_t' to 'unsigned int', possible loss of data
src/misc.c(457): warning C4267: 'function': conversion from 'size_t' to 'unsigned int', possible loss of data
- Compiling src/output.c
output.c
- Compiling src/read.c
read.c
src/read.c(3479): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data
C:\Users\sbeve\Downloads\make-4.4.1\src\read.c(2137) : warning C4701: potentially uninitialized local variable 'cmds' used
C:\Users\sbeve\Downloads\make-4.4.1\src\read.c(2137) : warning C4703: potentially uninitialized local pointer variable 'cmds' used
- Compiling src/remake.c
remake.c
- Compiling src/remote-stub.c
remote-stub.c
- Compiling src/rule.c
rule.c
- Compiling src/shuffle.c
shuffle.c
- Compiling src/signame.c
signame.c
- Compiling src/strcache.c
strcache.c
- Compiling src/variable.c
variable.c
C:\Users\sbeve\Downloads\make-4.4.1\src\variable.c(1891) : warning C4701: potentially uninitialized local variable 'origin' used
C:\Users\sbeve\Downloads\make-4.4.1\src\variable.c(1891) : warning C4703: potentially uninitialized local pointer variable 'origin' used
- Compiling src/version.c
version.c
- Compiling src/vpath.c
vpath.c
- Compiling src/w32/pathstuff.c
pathstuff.c
- Compiling src/w32/w32os.c
w32os.c
- Compiling src/w32/compat/posixfcn.c
posixfcn.c
- Compiling src/w32/subproc/misc.c
misc.c
- Compiling src/w32/subproc/sub_proc.c
sub_proc.c
- Compiling src/w32/subproc/w32err.c
w32err.c
- Compiling lib/fnmatch.c
fnmatch.c
- Compiling lib/glob.c
glob.c
- Compiling lib/getloadavg.c
getloadavg.c
- Compiling src\w32\compat\dirent.c
dirent.c

- Linking ./WinRel/gnumake.exe
   Creating library .\WinRel\gnumake.lib and object .\WinRel\gnumake.exp

.\WinRel build succeeded.
        1 file(s) copied.

C:\Users\sbeve\Downloads\make-4.4.1>pit install make
WARNING: Cannot create prebuild provider for repository 'core'.
Building dependency tree for make@4.4.1
make@4.4.1

Downloading make from 'https://ftpmirror.gnu.org/gnu/make/make-4.4.1.tar.gz' successful                                 Unpacking make [━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━] [100%]Building make@4.4.1 ⠸                                                                                                   WARNING: Script executed with status code 1
Last lines of script output:

Creating GNU Make for Windows 9X/NT/2K/XP/Vista/7/8/10/11

- Building without Guile
No MSVC compiler available.
Please run vcvarsall.bat and/or configure your Path.
ERROR: Cannot install package make
Caused by: Cannot build package
Caused by: Cannot execute build script
Caused by: Script executed with status code 1

C:\Users\sbeve\Downloads\make-4.4.1>cl
Microsoft (R) C/C++ Optimizing Compiler Version 19.51.36252 for ARM64
Copyright (C) Microsoft Corporation.  All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

C:\Users\sbeve\Downloads\make-4.4.1>

[BraveChicken1]

Thank you for pointing this out. Packit indeed does not let build scripts inherit the environment, instead we use a cleaned build environment which is managed by Packit. This environment ensures builds can find the correct dependencies and helps a bit in reproducibility.

The detection of MSVC is done inside the build scripts currently, but will be moved to the Packit application in the next version (see #121). The fix for this issue would then probably be to initialize the MSVC environment before calling build_w32.bat.

The strange thing however is that the make build_w32.bat seems to do the same detection as we do ourselves. Could you verify for me that the following command outputs the path to the installation of the VS Build Tools? "C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe" -latest -property installationPath

[mygizli04]

By default vswhere will only locate IDE installations, adding -products * will also find Build Tools

[BraveChicken1]

Thank you! The fix should then be pretty straightforward. I already added the initialization of the environment in pack-it/core#49 and I will add -products * to the MSVC detection code. This should then fix the issue.

[BraveChicken1]

I opened PR #130 to fix this issue. Could you verify for me that running the following command does actually find the VS Build Tools? "C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe" -latest -property installationPath -products * -requires Microsoft.VisualStudio.Component.VC.Tools.ARM64

[mygizli04]

Yes, it does locate it correctly.

[BraveChicken1]

Thank you for validating! The fix is merged and will be in the next release.