mirror of
https://github.com/OrcaSlicer/OrcaSlicer.git
synced 2026-09-01 06:16:58 +00:00
a15079ce08e0582f62346e5d14d554413f800cd2
3 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Gabriel Monteiro
|
cc390f11ee |
feat(build): build the missing dependencies from the main CMake configure (#15373)
* 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> |
||
|
Tobias Gloth
|
9d8c7cc495 | use /bigobj when building Eigen with MSVC (#13922) | ||
|
Donovan Baarda
|
dc5897d7b5 |
Update eigen to v5.0.1 and libigl to v2.6.0. (#11311)
* Update eigen from v3.3.7 to v5.0.1. This updates eigen from v3.3.7 released on December 11, 2018-12-11 to v5.0.1 released on 2025-11-11. There have be a large number of bug-fixes, optimizations, and improvements between these releases. See the details at; https://gitlab.com/libeigen/eigen/-/releases It retains the previous custom minimal `CMakeLists.txt`, and adds a README-OrcaSlicer.md that explains what version and parts of the upstream eigen release have been included, and where the full release can be found. * Update libigl from v2.0.0 (or older) to v2.6.0. This updates libigl from what was probably v2.0.0 released on 2018-10-16 to v2.6.0 released on 2025-05-15. It's possible the old version was even older than that but there is no version indicators in the code and I ran out of patience identifying missing changes and only went back as far as v2.0.0. There have been a large number of bug-fixes, optimizations, and improvements between these versions. See the following for details; https://github.com/libigl/libigl/releases I retained the minimal custom `CMakeLists.txt`, added `README.md` from the libigl distribution which identifies the version, and added a README-OrcaSlicer.md that details the version and parts that have been included. * Update libslic3r for libigl v2.6.0 changes. This updates libslic3r for all changes moving to eigen v5.0.1 and libigl v2.6.0. Despite the large number of updates to both dependencies, no changes were required for the eigen update, and only one change was required for the libigl update. For libigl, `igl::Hit` was changed to a template taking the Scalar type to use. Previously it was hard-coded to `float`, so to minimize possible impact I've updated all places it is used from `igl::Hit` to `igl::Hit<float>`. * Add compiler option `-DNOMINMAX` for libigl with MSVC. MSVC by default defines `min(()` and `max()` macros that break `std::numeric_limits<>::max()`. The upstream cmake that we don't include adds `-DNOMINMAX` for the libigl module when compiling with MSVC, so we need to add the same thing here. * Fix src/libslic3r/TriangleMeshDeal.cpp for the unmodified upstream libigl. This fixes `TriangleMeshDeal.cpp` to work with the unmodified upstream libigl v2.6.0. loop.{h,cpp} implementation. This file and feature was added in PR "BBS Port: Mesh Subdivision" (#12150) which included changes to `loop.{h,cpp}` in the old version of libigl. This PR avoids modifying the included dependencies, and uses the updated upstream versions of those files without any modifications, which requires fixing TriangleMeshDeal.cpp to work with them. In particular, the modifications made to `loop.{h,cpp}` included changing the return type from void to bool, adding additional validation checking of the input meshes, and returning false if they failed validation. These added checks looked unnecessary and would only have caught problems if the input mesh was very corrupt. To make `TriangleMeshDeal.cpp` work without this built-in checking functionality, I removed checking/handling of any `false` return value. There was also a hell of a lot of redundant copying and casting back and forth between float and double, so I cleaned that up. The input and output meshs use floats for the vertexes, and there would be no accuracy benefits from casting to and from doubles for the simple weighted average operations done by igl::loop(). So this just uses `Eigen:Map` to use the original input mesh vertex data directly without requiring any copy or casting. * Move eigen from included `deps_src` to externaly fetched `deps`. This copys what PrusaSlicer did and moved it from an included dependency under `deps_src` to an externaly fetched dependency under `deps`. This requires updating some `CMakeList.txt` configs and removing the old and obsolete `cmake/modules/FindEigen3.cmake`. The details of when this was done in PrusaSlicer and the followup fixes are at; * |