search

halide / Halide

a language for fast, portable data-parallel computation
https://halide-lang.org
Other
5.92k stars 1.07k forks source link

Halide:x86-windows build failed in VS 2022 #7667

Open LilyWangLL opened 1 year ago

LilyWangLL commented 1 year ago

Hello, I am a member of Microsoft VCPKG, now halide:x86-windows build failed on latest vcpkg, it failed with the following errors:

[1718/1732] cmd.exe /C "cd /D D:\buildtrees\halide\x86-windows-dbg\src\autoschedulers\adams2019 && D:\buildtrees\halide\x86-windows-dbg\bin\_Halide_gengen.exe -r adams2019_cost_model.runtime -o . -e object target=x86-32-windows,x86-32-windows"
FAILED: src/autoschedulers/adams2019/adams2019_cost_model.runtime.obj D:/buildtrees/halide/x86-windows-dbg/src/autoschedulers/adams2019/adams2019_cost_model.runtime.obj 
cmd.exe /C "cd /D D:\buildtrees\halide\x86-windows-dbg\src\autoschedulers\adams2019 && D:\buildtrees\halide\x86-windows-dbg\bin\_Halide_gengen.exe -r adams2019_cost_model.runtime -o . -e object target=x86-32-windows,x86-32-windows"
[1719/1732] cmd.exe /C "cd /D D:\buildtrees\halide\x86-windows-dbg\src\autoschedulers\adams2019 && D:\buildtrees\halide\x86-windows-dbg\bin\adams2019_cost_model.generator.exe -n adams2019_cost_model -d 0 -g cost_model -f cost_model -e c_header,object -o . target=x86-32-windows-no_runtime"
FAILED: src/autoschedulers/adams2019/adams2019_cost_model.h src/autoschedulers/adams2019/adams2019_cost_model.obj D:/buildtrees/halide/x86-windows-dbg/src/autoschedulers/adams2019/adams2019_cost_model.h D:/buildtrees/halide/x86-windows-dbg/src/autoschedulers/adams2019/adams2019_cost_model.obj 
cmd.exe /C "cd /D D:\buildtrees\halide\x86-windows-dbg\src\autoschedulers\adams2019 && D:\buildtrees\halide\x86-windows-dbg\bin\adams2019_cost_model.generator.exe -n adams2019_cost_model -d 0 -g cost_model -f cost_model -e c_header,object -o . target=x86-32-windows-no_runtime"
[1720/1732] cmd.exe /C "cd /D D:\buildtrees\halide\x86-windows-dbg\src\autoschedulers\adams2019 && D:\buildtrees\halide\x86-windows-dbg\bin\adams2019_cost_model.generator.exe -n adams2019_train_cost_model -d 0 -g train_cost_model -f train_cost_model -e c_header,object -o . target=x86-32-windows-no_runtime"
FAILED: src/autoschedulers/adams2019/adams2019_train_cost_model.h src/autoschedulers/adams2019/adams2019_train_cost_model.obj D:/buildtrees/halide/x86-windows-dbg/src/autoschedulers/adams2019/adams2019_train_cost_model.h D:/buildtrees/halide/x86-windows-dbg/src/autoschedulers/adams2019/adams2019_train_cost_model.obj 
cmd.exe /C "cd /D D:\buildtrees\halide\x86-windows-dbg\src\autoschedulers\adams2019 && D:\buildtrees\halide\x86-windows-dbg\bin\adams2019_cost_model.generator.exe -n adams2019_train_cost_model -d 0 -g train_cost_model -f train_cost_model -e c_header,object -o . target=x86-32-windows-no_runtime"
ninja: build stopped: subcommand failed.

The reason for the installation failure is that files adams2019_cost_model.h and adams2019_train_cost_model.h were not generated. However, this port builds successfully on x64-Windows, and files adams2019_cost_model.h and adams2019_train_cost_model.h are correctly generated.

I checked the codes in https://github.com/halide/Halide/blob/9755e3da001e6c53898241a691259c2a3039e81c/cmake/HalideGeneratorHelpers.cmake#L448C1-L460C33, but I did not find any abnormalities. Could someone help to investigate this issue?

I use Visual Studio 2022 17.6.3, if need other informations, please ping me. Thanks in advance.

The following files are config and build logs.

install-x86-windows-dbg-out.log config-x86-windows-out.log

abadams commented 1 year ago

What should I do to reproduce? The following seems to work fine for me with latest visual studio 2022

vcpkg install halide:x86-windows --recurse
LilyWangLL commented 1 year ago 
Installing 5/5 halide:x86-windows...
Building halide[core,target-x86]:x86-windows...
-- Downloading https://github.com/halide/Halide/archive/v15.0.0.tar.gz -> halide-Halide-v15.0.0.tar.gz...
-- Extracting source F:/0711/downloads/halide-Halide-v15.0.0.tar.gz
-- Using source at F:/0711/buildtrees/halide/src/v15.0.0-f49c30d139.clean
-- Found external ninja('1.11.0').
-- Configuring x86-windows
-- Building x86-windows-dbg
CMake Error at scripts/cmake/vcpkg_execute_build_process.cmake:134 (message):
    Command failed: F:/0711/downloads/tools/cmake-3.25.1-windows/cmake-3.25.1-windows-i386/bin/cmake.exe --build . --config Debug --target install -- -v -j17
    Working Directory: F:/0711/buildtrees/halide/x86-windows-dbg
    See logs for more information:
      F:\0711\buildtrees\halide\install-x86-windows-dbg-out.log

Call Stack (most recent call first):
  installed/x64-windows/share/vcpkg-cmake/vcpkg_cmake_build.cmake:74 (vcpkg_execute_build_process)
  installed/x64-windows/share/vcpkg-cmake/vcpkg_cmake_install.cmake:16 (vcpkg_cmake_build)
  ports/halide/portfile.cmake:52 (vcpkg_cmake_install)
  scripts/ports.cmake:147 (include)

PS F:\0711> .\vcpkg.exe --version
vcpkg package management program version 2023-06-22-f19f3d9939100085fe2f7e41502d60b08e2083b6

This issue still exists on the latest vcpkg.

abadams commented 1 year ago

I have the same vcpkg version, so I'm not sure what I'm doing differently. Is the command-line I wrote above the right one? I'm a bit of a vcpkg noob.

LilyWangLL commented 1 year ago

Could you please try .\vcpkg install halide:x86-windows --binarysource=clear?

abadams commented 1 year ago

Here's what I get (in a VS 2022 developer command prompt):

E:\vcpkg>vcpkg remove halide
warning: Starting with the September 2023 release, the default triplet for vcpkg libraries will change from x86-windows to the detected host triplet (x64-windows). To resolve this message, add --triplet x86-windows to keep the same behavior.
The following packages will be removed:
    halide:x86-windows
Removing 1/1 halide:x86-windows

E:\vcpkg>vcpkg install halide:x86-windows --binarysource=clear
Computing installation plan...
The following packages will be built and installed:
    halide[core,target-x86]:x86-windows -> 15.0.0#1
Detecting compiler hash for triplet x86-windows...
Installing 1/1 halide:x86-windows...
Building halide[core,target-x86]:x86-windows...
-- Using cached halide-Halide-v15.0.0.tar.gz.
-- Cleaning sources at E:/vcpkg/buildtrees/halide/src/v15.0.0-f49c30d139.clean. Use --editable to skip cleaning for the packages you specify.
-- Extracting source E:/vcpkg/downloads/halide-Halide-v15.0.0.tar.gz
-- Using source at E:/vcpkg/buildtrees/halide/src/v15.0.0-f49c30d139.clean
-- Configuring x86-windows
-- Building x86-windows-dbg
-- Building x86-windows-rel
-- Installing: E:/vcpkg/packages/halide_x86-windows/share/halide/copyright
-- Performing post-build validation
Elapsed time to handle halide:x86-windows: 14 min
Total install time: 14 min
The package halide provides CMake targets:

    set(CMAKE_CXX_STANDARD 17)
    set(CMAKE_CXX_STANDARD_REQUIRED YES)
    set(CMAKE_CXX_EXTENSIONS NO)

    find_package(Halide REQUIRED)

    # JIT mode:
    add_executable(my_halide_app main.cpp)
    target_link_libraries(my_halide_app PRIVATE Halide::Halide)

    # AOT mode:
    add_executable(my_generators my_generators.cpp)
    target_link_libraries(my_generators PRIVATE Halide::Generator)
    add_halide_library(my_first_generator FROM my_generators)
    add_halide_library(my_second_generator FROM my_generators
        PARAMS parallel=false scale=3.0 rotation=ccw output.type=uint16)
    add_halide_library(my_second_generator_2 FROM my_generators
        GENERATOR my_second_generator
        PARAMS scale=9.0 rotation=ccw output.type=float32)
    add_halide_library(my_second_generator_3 FROM my_generators
        GENERATOR my_second_generator
        PARAMS parallel=false output.type=float64)

For more information see:
    https://github.com/halide/Halide/blob/v15.0.0/README_cmake.md

E:\vcpkg>vcpkg --version
vcpkg package management program version 2023-06-22-f19f3d9939100085fe2f7e41502d60b08e2083b6

See LICENSE.txt for license information.
abadams commented 1 year ago

Here's a hypothesis: The step that's failing on vcpkg CI (but not for me) is a generator invocation. Sometime recently we added a default timeout to generators of 15 mins (IIRC). The windows-x86-dbg build produces very slow binaries. Maybe on some machines it's taking more than 15 mins to run the generator that's part of the Halide build. If that's true, we should change our cmake config to give it an infinite timeout.

@steven-johnson sound plausible?

steven-johnson commented 1 year ago

Possible, yes... plausible, eh, I dunno. 15 minutes is a long time to run a Generator. Even in debug mode that's a long time.

abadams commented 1 year ago

Asking a windows debug build of llvm to compile anything is glacially slow. In the past we've told people to never use debug builds on windows because it's so slow that it's basically non-functional. On my home gaming machine running the cost model generator took several minutes. I could easily imagine that breaking a 15 minute threshold on a weaker CI machine.

But my real point is that surely we shouldn't let the compilation of libHalide fail just because it's taking a long time. The timeout on the cost model generator should be infinite.

steven-johnson commented 1 year ago

Yeah -- IMHO the timeout should be in the build system, not the Generator

kwsp commented 9 months ago

I believe the VCPKG build of Halide is still broken- are there any updates?