Windows cross-compile support on Linux #2841
Conversation
boberfly
force-pushed
the
windowsCrossCompile
branch
3 times, most recently
from
fe125bf
to
4c5c4fd
Compare
|
Hmm odd that the CI can't find |
It looks like you install winsdk in |
There was a problem hiding this comment.
In superbuild, we need to pass value of winsdk path to ISPC CMake, something like this is needed around line 723-724:
if (NOT WIN32 AND NOT APPLE)
if (ISPC_CROSS)
list(APPEND ISPC_COMMON_CMAKE_ARGS
-DISPC_WINDOWS_SDK_PATH=${ISPC_WINDOWS_SDK_PATH}
)
endif()
endif()There is also this place https://github.com/ispc/ispc/blob/main/cmake/GenerateBuiltins.cmake#L294-L300 that maybe needs to be changed. Please, leave a TODO there.
Ahh silly me my mind was registering that LLVM_HOME as ISPC_HOME thanks for that! |
boberfly
force-pushed
the
windowsCrossCompile
branch
from
4c5c4fd
to
c5c092b
Compare
boberfly
force-pushed
the
windowsCrossCompile
branch
from
c5c092b
to
32b8958
Compare
There was a problem hiding this comment.
Thanks for the PR, I like the proposed changes, it create a good path for solving the issue that we had for some time.
I guess the intention is not just enable Linux->Windows cross compilation for developer builds, but enable it for release builds. If Windows SDK license allows this, I guess we can do that.
| @@ -87,6 +87,8 @@ for: | |||
| export CROSS_TOOLS=/usr/local/src/cross | |||
| export WASM=OFF | |||
| export LLVM_TAR=llvm-17.0.6-ubuntu18.04-Release+Asserts-x86.arm.wasm.tar.xz | |||
| export XWIN_HOME=$APPVEYOR_BUILD_FOLDER/xwin | |||
There was a problem hiding this comment.
I like the approach with xwin.
But I'm concerned that it's a personal project, which we supposed to download from personal github releases of project and use in the CI. The project is nice and it's not too hard to review it to make sure that it doesn't pose a security threat. But there's no mechanism to verify that it's not modified (even if we use a fixed version), unless we download a SHA256 and keep in our secrets (which is also a possible mitigation).
What would solve this problem is to distribute xwin through one of the package managers. Do you know if it's available through one of them or is it possible to request that?
There was a problem hiding this comment.
Yeah that's definitely a valid point, I've not got the answer to this one except for perhaps using cargo directly at this point. Maybe we can get @Jake-Shadle into the conversation about this one as well.
There was a problem hiding this comment.
I never package projects I maintain, if you don't trust the github releases you can use cargo install I suppose to build it yourself before running it, though obviously at the cost of a lot of CPU work.
There was a problem hiding this comment.
@Jake-Shadle Thanks for commenting on that and thanks for the nice tool.
This is the code that runs in trusted environment, i.e. has access to github secrets, affects what is linked in to the binaries we ship, etc. So it requires some procedures in place to ensure security and integrity of the result. And operating in enterprise environment requires taking these kind of things more serious.
So I guess we can cache the SHA256 of the package in out secrets and use the file from github releases. That's would be the easiest for everyone.
But that would really, really help adopting xwin if it's available through some package manager. apt, snap, or whatever.
There was a problem hiding this comment.
IMO it would be easiest to just create a tarball or container image with the CRT/SDK in it that you can download in your CI, they don't change frequently and it means you don't run any code at all.
There was a problem hiding this comment.
If we run it in public CI, then the image needs to be in public, this implies that we are responsible for it and we need to review with security people, maintain, etc. And this is something we definitely don't want to do.
xwin seems to be ideal tool for that purpose. If it would only be shipped though some package manager... ;-)
| @@ -243,6 +241,9 @@ function(builtin_to_cpp bit os_name arch supported_archs supported_oses resultFi | |||
| if (${os_name} STREQUAL "macos") | |||
| # -isystem/iusers/MacOSX10.14.sdk.tar/MacOSX10.14.sdk/usr/include | |||
| set(includePath -isystem${ISPC_MACOS_SDK_PATH}/usr/include) | |||
| elseif (${os_name} STREQUAL "windows") | |||
| # -isystem/xwin/crt/include -isystem/xwin/sdk/include/ucrt | |||
| set(includePath -isystem${ISPC_WINDOWS_SDK_PATH}/crt/include -isystem${ISPC_WINDOWS_SDK_PATH}/sdk/include/ucrt) | |||
There was a problem hiding this comment.
@nurmukhametov Couple you please verify that "default" build without cross compilation enabled is not affected?
Very similar to #2758 but it uses the windows toolchain via https://github.com/Jake-Shadle/xwin