[halide] Update to version 10.0.0 #13860
Conversation
|
|
This is following the recommendations in a conversation I had with Robert Schumacher on the #vcpkg CppLang Slack channel. This recommendation was derived from the fact that "cmake defaults module DLLs into the lib folder, which makes vcpkg's current policy very inconvenient for authors" and that I do not plan to enable build systems other than CMake.
|
x86-windows is failing due to this compiler bug in MSVC: https://developercommunity.visualstudio.com/content/problem/1179643/msvc-copies-overaligned-non-trivially-copyable-par.html LLVM has a patch for this in trunk, but backporting it should be a separate PR... https://reviews.llvm.org/rG4e3edef4b8b637c0c76897497eb7c66f00157210 |
|
This is ready for review if any of y'all have a chance to take a look! |
LilyWangL
added
category:port-update
|
@alexreinking Thanks for your PR. When I installing |
|
That is a known issue with MSVC mis-compiling LLVM. There's a link to the MSVC issue in the CI baseline. It's also mentioned in my second comment, higher in this PR. Until that is fixed, Halide will not work with or without this PR. It's only because we now execute some Halide code during the v10 build that this is appearing. The problem is between LLVM and MSVC. Note that this only affects x86-windows-dbg. Release mode on x86 works, as does all of x64 |
I test all features on x64 and they work fine. |
LilyWangL
removed
the
requires:all-feature-testing
Co-authored-by: NancyLi1013 <46708020+NancyLi1013@users.noreply.github.com>
|
Thanks for the reviews @LilyWangL and @NancyLi1013! Is there anything else that needs to be done before merging? |
dan-shaw
added
requires:author-response
and removed
info:reviewed
|
Thanks for the PR! |
[halide] Update to version 10.0.0 (microsoft#13860)
I thought I would take a shot at updating Halide to version 10.0.0. This is my first PR for vcpkg, so I apologize in advance for anything I did wrong.
This PR updates Halide to version 10.0.0 which was released a few weeks ago.
Attn: @LilyWangL (we spoke on a related issue on the Halide tracker: halide/Halide#4539)
Attn: @NancyLi1013 (we spoke on #11761)
Attn: @qis (we spoke on the CppLang Slack a couple weeks ago)
Attn: @ras0219-msft (we spoke on the CppLang Slack today)
Fixes #13580
Fixes #13823
Halide doesn't work with ump or emscripten because it JIT compiles. CI is set to skip
x86-windowsbecause the debug configuration is broken by MSVC mis-compiling LLVM (see my comment below)Users should also avoid linking to Halide statically, especially on macOS and Linux. The autoscheduler plugins do not support building Halide as a static library and are a critical feature. I could be convinced to print a warning, but it is surprising to me that on OS X and Linux, that static libraries are the default. I have used
vcpkg_check_linkage(ONLY_DYNAMIC_LIBRARY)here.Yes, but with one exception: this PR also fixes the LLVM port features to allow correct dependencies in Halide's features.
Here's the problem: The
target-allfeature of LLVM is disconnected from the other target features, such astarget-nvptx. So enabling the NVPTX backend in Halide would depend on EITHERllvm[core,target-nvptx]ORllvm[core,target-all], which isn't possible. I reworked thetarget-allfeature of LLVM to depend onllvm[core,target-aarch64,...,target-xcore], which fixes the issue (and simplifies the portfile as a bonus). Now Halide'starget-nvptxfeature depends correctly onllvm[core,target-nvptx]and it will still work when the user previously installedllvm[target-all].This is sort of a grey area by my reading of the Maintainer Guide. Changing LLVM in this way would seem frivolous were it not for the fact that Halide needs this change. I'm breaking the tie between "Make separate Pull Requests per port" and "Avoid trivial changes in untouched files" in favor of the latter since my primary goal is updating the Halide port.
I did split the changes into two commits in case I made the wrong call here and you want me to open a separate PR for the LLVM changes.