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.
Try manually to propagate the local environment variable for the dyld framework path
It might not get propagated across the process boundaries by itself the way github actions set it in the local environment.
Looks like the test executable need to be run from the cmake root build directory,
because it hardcodes a relative path to the library api/sixtyfps-cpp/libsixtyfps_cpp.so
This might actually be a corrosion bug.
