* 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.
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.
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.
Even if SIXTYFPS_BACKEND_GL is set to OFF, we would default to enabling
X11, which translates to enabling the x11 feature, which in turn
implicitly activates the GL backend. In addition, the interpreter Rust
API crate also enables the GL backend in its defeaults.
In order to make it possible to turn off the GL backend, three changes are necessary:
* The default backend no more selects a default :-). Instead the Rust
API crate, Rust interpreter API crate and the CMake project define
the same features and defaults.
* The C++ crate depends on the interpreter without its defaults (which enable GL)
* In CMake the X11 and Wayland features become dependent options, that
are only show in the CMake configure UI if the GL backend is enabled.
This way a GL-disabled build won't also pass --features x11.
As we try to copy the different location target properties from the
corrosion target into the package config file, we need to take all the
usual build types into account, not only Debug/Release.
Especially RelWithDebInfo is popular among packagers.
Select that the compiler and xtask should be compiled as host binaries,
not target.
This also pulls in new corrosion with better cross-compilation support.
When using cmake to configure the C++ build and Qt is found, and then
build with `SIXTYFPS_NO_QT=0 cmake --build ..`, the C++ library is built
without Qt support but qt_viewer is built. Linkage then fails when it
tries to access the API in libsixtyfps_cpp.so that provides the QWidget,
as that symbol is not present.
So with newer CMake we use find_package to provide positive information
to the cargo build about where Qt is, and consequently this patch
provides negative information to disable Qt support if CMake could not
find Qt -- or it was deliberately disabled for example using
`-DCMAKE_DISABLE_FIND_PACKAGE_Qt5=1`.
cc #232
find_package(Qt5) may do a better job at finding qmake, especially if the build is invoked
through Qt Creator, which may make sure that CMAKE_PREFIX_PATH is set.
Forward the qmake path therefore the the rust build.
Map the target_pointer_width cfg's used for the opaque ffi interpreter
data structures to #ifdefs in CMake, to avoid that cbindgen generates
them multiple times without guard.
Try adding an LC_RPATH command to the cdylib that we're building (for example libsixtyfps_cpp.dylib),
to fix linkage against Qt, which uses `@rpath/QtCore.framework/XXX` for inter-library linkage dependencies.
