mirror of
https://github.com/OrcaSlicer/OrcaSlicer.git
synced 2026-08-30 13:26:58 +00:00
cc390f11ee
* fix(deps): build the dependencies from scratch with clang-cl Six dependencies fail once the superbuild compiles them with clang-cl instead of cl: - OpenSSL never goes through CMake. Its VC-WIN64A makefile only works with cl, and an unquoted clang-cl path with spaces produces no .obj files at all, so the lib step dies with LNK1181. Pin the upstream toolchain. - Boost.Container's bundled dlmalloc passes int* to the Interlocked API. cl warns, clang rejects it. - curl 7.75's configure probes rely on C laxness clang rejects. The results flip and nonblock.c ends up in the AmigaOS IoctlSocket branch. - OCCT installs RelWithDebInfo into bini/libi while find_package looks in lib. It also prepends -Wl,-s to the shared linker flags for every Clang build, which the MSVC-style linker gets as an argument it does not know. Both patched hunks sit inside if (MSVC) in the OCCT sources. - wxWidgets lands in lib/clang_x64_lib, so wxWidgetsConfig.cmake falls back to the layout that exists instead of assuming vc_x64_lib. It tries the derived path first, so a cl-built tree consumed by clang-cl keeps resolving the way it does today. The patch step also resets the one file it touches, so it can run again after an interrupted build or after the patch itself changed. - wxInspector goes through FindwxWidgets, which only searches lib/vc*_lib because _WX_TOOL is hardcoded to vc. It now gets the root and lib dir derived the same way wxWidgetsConfig.cmake derives them. Eigen is the seventh, and it breaks on the generator rather than the compiler. Its test, lapack and blas/testing subdirectories all call enable_language(Fortran), and they default to ON because the dependency configures as its own top-level project. Whether that hurts depends on what CMake finds: the Visual Studio generator supports no Fortran and finds nothing, clang-cl sits next to the LLVM toolset's flang and works, while MSVC with Ninja finds Strawberry Perl's MinGW gfortran, which this build already requires for OpenSSL, and hands it the MSVC-style /machine:x64 that MinGW's ld reads as a missing input file. The configure dies there and takes every dependency still in flight with it. Only the headers are consumed here, so the three subprojects are off. * fix(deps): honor the superbuild's generator and compiler in sub-builds orcaslicer_add_cmake_project pinned every dependency sub-build to the Visual Studio generator whenever MSVC was true, which is also true for clang-cl. That generator selects its compiler by toolset and ignores the CMAKE_C_COMPILER and CMAKE_CXX_COMPILER this file already forwards, so the dependencies were built with cl.exe no matter which generator or compiler the superbuild was given. Key the three affected decisions on the generator instead: which generator the sub-builds use, whether CMAKE_BUILD_TYPE is forwarded, and /m versus -j. A Visual Studio superbuild is unchanged, so the default path and CI behave exactly as they do today. build_release_vs.bat now accepts -l to select clang-cl, alongside the existing -x for Ninja, so the generator and the compiler can be chosen independently. On the Visual Studio generator -l reaches the slicer only, through the ClangCL toolset, because the dependency sub-builds have no toolset to inherit; a deps build in that combination says so rather than quietly using MSVC. * fix(deps): use upstream wxWidgets compiler layout fix The compiler-prefix layout fix now comes from SoftFever/Orca-deps-wxWidgets#7, so remove the duplicated local patch and apply step. * fix(deps): stop Assimp enabling ccache on the RC rule ASSIMP_BUILD_USE_CCACHE defaults on and applies the launcher through the global RULE_LAUNCH_COMPILE property, so it wraps the resource-compiler rule as well. Under Ninja that rule goes through cmcldeps, which does not survive being launched by ccache, and the build fails with clang-cl reporting /fo as a missing file. The superbuild already forwards CMAKE_<LANG>_COMPILER_LAUNCHER, which CMake applies per language and so keeps clear of the RC rule. --------- Co-authored-by: SoftFever <103989404+SoftFever@users.noreply.github.com> Co-authored-by: raistlin7447 <kris.austin@gmail.com>