As per commit 69feb7f0f40cc8dc4ca52777cf87a4c879d4b953 in meta-slint and
others, the Skia build is tricky because clang needs to be indirectly
and carefully instructed where gcc headers are located. In the Yocto
recipes, we go through lengths to set CLANGCC/CLANGXX correctly so that
the --target matches the triplet sub-directories in
recipe-sysroot/usr/lib and recipe-sysroot/usr/include/c++/$ver/ .
For aarch64 it's simple, there's usually just aarch64-$distro-linux, but
for example for armv7-$distro-linux-gnueabihf magic has to come
together: The gcc install dir is typically
recipe-sysroot/usr/lib/arm-$distro-linux-gnueabi (note the v7 and hf
absence). That means that's what --target needs to be when invoking
clang. But now the `hf` suffix is gone, which means clang relies on for
example -mfloat-abi=hard to avoid the use of gnu soft-float stubs. All
that's meticulously prepared in the Yocto recipe and placed for easy
consumption in CLANGCC/CLANGCXX environment variables. Therefore, when
those environment variables are set, don't overwrite them in
CORROSION_ENVIRONMENT_VARIABLES.when those environment variables are
set, don't overwrite them in CORROSION_ENVIRONMENT_VARIABLES.
This reverts commit 292f487815.
Olivier had the brilliant idea of preceeding the path with a slash
on the Yocto side, so we can go back to the correct "type".
This reverts commit 0773e51d92.
By the SLINT_COMPILER being a `FILEPATH`, cmake will convert any
relative path to an absolute path. That's not wanted for the Yocto
build, because there we pass
'$ENV{OECORE_NATIVE_SYSROOT}/usr/bin/slint-compiler', so that
the path is resolved dynamically against the environment variable that
the Yocto SDK sets.
CMake would convert this to an absolute path that points into the build
directory, i.e. it would be /home/blah/foo/\$ENV{...}
Commit 9b62b08ed6 fixed
https://github.com/slint-ui/slint/issues/1066 initially, but commit
1036c0d082 erroneously regressed this
again, because while Corrosion sets this property, it is only set on the
locally generated CMake target. We still need to propagate that also
into the installed CMake target, which this patch does.
When building with cmake, buildroot sets PKG_CONFIG_SYSROOT_DIR in its
toolchain file, and therefore it's only available at configure time but
not build time, which is when our dependencies need it.
Since commit 7947f233f1a744f5ce9dfdf44372727d4fefb50b in Corrosion,
cmake will default to ${CMAKE_C_COMPILER} for linking a cdylib,
which means that C must be enabled as a language in the project.
Previously, it tried C, CXX, and Fortran and picked the first one.
... and to use an external compiler
For example, this is how one only build the compiler:
```
cmake .. -DSLINT_BUILD_RUNTIME=OFF -DCMAKE_INSTALL_PREFIX=/tmp/slint_compiler
make install
```
And this only build the runtime
```
cmake .. -DSLINT_FEATURE_COMPILER=OFF -DCMAKE_INSTALL_PREFIX=/tmp/install_runtime
make install
```
And then this can be used in a project like so:
```
cmake .. -DCMAKE_PREFIX_PATH=/tmp/install_runtime/ -DSLINT_COMPILER=/tmp/install_compiler/bin/slint-compiler
```
Many of our dependencies already made the jump and require a cargo update hack, so make it official
Removed the MSRV from the README since it applies to master branch and people read the readme also for
the released version. There is enough documentation of the MSRV in other locations.
This doesn't require a windowing system, just Linux and Vulkan drivers
that supports the display extensions.
It's called linuxkms as soon this will go beyond Vulkan and also support
EGL and perhaps dumb buffers for software rendering.
This isn't supported on desktop yet, but on MCU it is.
Cargo is instructed to build a dylib and a staticlib, but corrosion
instructs rustc to build only either dylib or staticlib.
Corrosion listens to the BUILD_SHARED_LIBS option and will change the
default for the Slint::Slint INTERFACE_LINK_LIBRARIES to either
slint-cpp-shared or slint-cpp-static. This way the selection is
transparent to the users.
