When the workflow is triggered via workflow_call, the input
is in different variables unfortunately. Try to use the same trick as in
sixtyfps_tool_binary.yaml.
Always build the vs code extension, the regular CI should be the guard in the future and this needs condition somehow doesn’t work (never triggers despite all green)
This requires adding Cargo features to the lsp in order to be able to
make a build that doesn't use the GL backend. In theory --features
sixtyfps-interpreter/backend-qt could be used to opt into Qt, but
there's no way of turning off the gl backend AFAIK - hence the features
in the lsp.
This splits the docs and wasm workflows into shared files, that will be
called (for QA purposes) from ci.yaml as well as from nightly_snapshot
(for publishing).
The viewer build is also triggered by the snapshot workflow.
We can't support it with the interpreter, and the compiler running on wasm
is only used for the interpreter.
And this cause compilation issue because some dependencies enable features
that breaks the build
For the MCU port, we need to proccess the image to save them in the binary
in a convenient format.
This patch start this work by trying to anaylyze what format should an image
be using, and saving it as a texture in the binary.
The current graphical backend and the C++ frontend are not yet supported
The default backend does not select any features or backends by default
on the Cargo.toml feature level. And with this change it also doesn't do
that anymore based on the target platform.
That means if the rust api crate is built with default-features = false,
no backend will be selected and the user has to take care of backend
initialization through other means.
The feature defaults, generally, are in the rust API crate, the
interpreter crate and C++ CMakeLists.txt. The latter triggers a cargo
build of sixtyfps-cpp with --no-default-features. However the cpp_test
job in the CI doesn't build sixtyfps-cpp with CMake but instead calls
cargo directly. Therefore the defaults are now also coded in the
sixtyfps-cpp Cargo.toml, to ensure that *a* rendering backend is chosen
(since the cfg.target bit is gone).
The objective is to split up the workflows, which requires the existence
of the *new* workflow files in the master branch in order to trigger
test builds in a branch.
We copy the sixtyfps_cpp.dll into the bin directory where the examples
are, but that needs to be a Debug/ or Release/ sub-directory in case of
a multi-config generator.
The function that expose the vtable was not exported because the declare_item_vtable
expanded to a `#[cfg(feature = "ffi")]` with the intention to be the ffi feature
of the corelib crate. But when this macro is used from the qt backend, the ffi
feature was not set
