* ci: build the Windows x64 dependencies and slicer with clang-cl
Passes -l -x from the Windows jobs, using the clang-cl and Ninja options
added in #15373. Ninja runs each dependency's build step as a plain command,
so the jobs set up a VC environment for OpenSSL's nmake. arm64 stays on MSVC
for now.
The deps cache key gains the compiler, so windows-x64 becomes
windows-x64-clang and windows-arm64 becomes windows-arm64-msvc.
* deps: select OpenSSL's ARM64 target from DEPS_ARCH
CMAKE_GENERATOR_PLATFORM is only set by -A, which Ninja never receives, so
the Ninja build selected the x64 target on ARM64. DEPS_ARCH is derived from
CMAKE_SYSTEM_PROCESSOR and is already independent of the generator.
* ci: build the Windows ARM64 dependencies and slicer with clang-cl
Three dependencies need handling first. libpng and OpenCV each build an ARM
SIMD path that does not compile with clang-cl, so those paths are off; PNG
already had the same opt-out for Apple ARM. OCCT is built with cl, since
clang-cl cannot emit one of its large generated files and there is no option
to turn that off. All three are gated to Windows ARM64 with clang.
* 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>
* Revert 98be94a729
We carry a wxgtk patch [1] that detects dark theme automatically. If it
doesn't work, it means that either selected Gtk theme is not installed
in flatpak environment, or appropriate xdg-desktop-portal for the DE is not
installed.
Plasma users may need to install org.gtk.Gtk3theme.Adapta
Also see https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.Settings.html
[1] 0001-Enable-using-a-dark-theme-when-Gnome-dark-style-is-s.patch
* flatpak: introduce ORCA_SLICER_DARK_THEME to force dark theme
If ORCA_SLICER_DARK_THEME is set, dark theme will be applied regardless
of system settings.
* FIX: occt build failure
Pick up build error fix from upstream:
7236e83dcc
/run/build/BambuStudio/deps/build/dep_OCCT-prefix/src/dep_OCCT/src/StdPrs/StdPrs_BRepFont.cxx: In member function ‘Standard_Boolean StdPrs_BRepFont::renderGlyph(Standard_Utf32Char, TopoDS_Shape&)’:
/run/build/BambuStudio/deps/build/dep_OCCT-prefix/src/dep_OCCT/src/StdPrs/StdPrs_BRepFont.cxx:465:30: error: invalid conversion from ‘unsigned char*’ to ‘const char*’ [-fpermissive]
465 | const char* aTags = &anOutline->tags[aStartIndex];
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| unsigned char*
* Set policy CMP0167 to NEW
Newer cmake switched to using BoostConfig.cmake shipped with boost-1.70
or later for detecting boost, to preserve old behavior policy CMP0167
was introduced.
Set it to "NEW" to indicate that we want to use .cmake shipped with
boost
* Add OpenSSL tarball link to the manifest
* Add curl zip to the manifest
* flatpak: bump runtime version to 47
Gnome 47 has been released a while ago
---------
Co-authored-by: Bastien Nocera <hadess@hadess.net>
* Fix OCCT and OpenCV patching during build
The inclusion of the `--directory` flag here isn't necessary because of
how `PATCH_COMMAND` applies patches. In fact this causes issues when
trying to build from an archive, `--directory` seems to imply `--index`
and thus this patch only succeeds if you're inside an initialized git
repo. If you simply use the archive without a git repo the build fails
at the patch step.
* Alter patch command based on git repo status
`git apply` has different behavior when inside a git repo vs not. If
we're in a git repo we need to fully quality the path for these patches,
otherwise we can omit the directory flag.
---------
Co-authored-by: Joe Palazzolo <joe@joepalazzolo.net>
* Initial commit for the builder
* fix wx, use hack to install into /app
* add some workarounds for /usr/local
* fix up rest of paths
* attempt to fix wxwebview undef
* figure out why wxwidgets isnt getting its patches applied
* do "proper" patching of wxwidgets
* Flip the flag
* actually append the /usr/local
* restrict package finding to flatpak only
* Update the destdir stuff for mpfr, gmp
* Transfer over all the _destdir, again
* update patch command for all other plats
* initial ci check
* what even happened
* clear ci image
* I doubt this will do anything
* do cleanup after running each step
* remove build objects for flatpak ci
* compress debug info
* Fix MacOS build
* Try saving space after building deps
* No debug info for now
* Do debug info, use thin static archives
* use BSD flag, not --thin
* try building with lto
* Use release, no debug info
* remove lto
* Revert the last 5 commits
* It might require write perms
* Revert "It might require write perms"
This reverts commit 44cec58a57.
* Import fixes for merge
* remove some patch stuff
* the worst hack!
* remove uneeded patches
* Initial commit for the builder
* note to self, go back to regular wx
* attempt to fix wxwebview undef
* do "proper" patching of wxwidgets
* update patch command for all other plats
* what even happened
* -ldep_name-NOTFOUND is still here
* concat patches
* Build wx with flatpak
* more wx shenatigans
* fix a missing import
* build wx with proper flags
* fix imports and libs
* trigger ci
* try fixing mac and windows ci
* remove duplicate definition of freetype
* curl may not have openssl for a dep
* has openssl been found?
* force building
* build images on apple
* cleanup for review
* cleanup cmake files
---------
Co-authored-by: SoftFever <softfeverever@gmail.com>
