* Rename the package to `SixtyFPS-cpp-*` to make it easier to see that these are for C++
* Refer to the download and extraction process in the two C++ "READMEs"
* Set the home page url in the cmake project() command, from where cpack will pick it up for inclusion in the installer.
cc #631
We bundle Qt and Qt needs the VC runtime DLLs. There are two options:
Find and locate vcredist.exe, include it in the NSIS installer and run
it. Alternatively, a cmake module exists to locates the DLLs and
install them.
This patch uses the latter option, for simplicity. When upstream ticket
https://gitlab.kitware.com/cmake/cmake/-/issues/17725 is implemented, we
could switch to the first option.
Note: This might include a few DLLs that Qt probably doesn't
need.
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).
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.
Similar to the parent commit, the model tracks changes to the rows and
marks an internal property dirty. Since we have a base class this is a
little less intrusive.
cc #98
This allows compiling with SIXTYFPS_EMBED_RESOURCES=true and
images/fonts are embedded as inline variables.
Generated data is emitted into the header file as
inline uint8_t sfps_embedded_resources_123[789] = {
0x1, 0x2, 0x3,
};
Don't generate the headers by default in the source directory, put them
into a sub-directory in OUT_DIR instead and convey that location via
links to the C++ test driver.
Make install would still trigger the generated_headers_target CMake
custom command - due to the use of add_dependencies - and that would end
up running cbindgen. That in turn breaks "make install" when it's run in
an environment that doesn't have cargo in PATH (for example when using
"sudo make install").
This patch folds the generation of the C++ header files into the build
of the sixtyfps-cpp crate - via build.rs. By default the headers are
placed in api/sixtyfps-cpp/generated_include but the CMake build
redirects that into the build directory.
Note: Due to the way that corrosion works, cargo is still run when
running "make install", but it's path is absolute and there should not
be any reliance on the PATH environment variable.
The upcoming re-organization of the C++ header generation requires the
use of the CORROSION_ENVIRONMENT_VARIABLES target property, which in
turn requires CMake >= 3.19.
