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.
The problem is that the backend is using the `meta_property_listener` to know
if the layout must be updated, but the C++ code would not register a dependency
NOTE about the test: The test doesn't really test that it works because
the test backend don't have a meta_property_listener and apply the layout
inconditionally in sixtyfps_send_mouse_click
This is just a starting point, to be turned into a real Transform
element later, along with syntactic sugar to turn rotation, etc. into a
transform matrix in the generated output.
In the nightly it appears that `no_mangle` is now considered "unsafe",
so we need to allow that in the ffi modules. For the layout code this
patch also creates that ffi module with prefixed function names, like in
the other modules and only allows unsafe in there.
Allow converting a brush to a color. In the case of a gradient, the color of the first stop is returned.
For the C++ generator this requires adding the extra case of explicitly
calling the `Brush(const Color &)` constructor, despite it being implicit,
in order to generate the correct code when we have IR that casts twice:
```
Expression::Cast {
from: Expression::Cast {
from: Expression::Cast {
from: Expression::NumberLiteral(...),
to: Type::Color,
}
to: Type::Brush,
},
to: Type::Color,
}
```
A few changes were required:
* `LinearGradient(LinearGradient)` as enum variant unfortunately
won't compile because the cbindgen generated constructor
function (`LinearGradient()`) will try to also instantiate the
variant type inside (`LinearGradient`) and that won't find the type
but the function itself and error out. So the inner type is now
called `LinearGradientBrush`.
* The same name dance was required for `Color`, where the enum variant
instead is called `SolidColor`
* `BrushInner` was removed in favor of just `Brush`. The nicer Rust
API will be the public variant, and for cbindgen we can just put
the generated enum into an internal namespace, like we do for
Resource for example
* A `NoBrush` variant was added. Maybe that name could be improved?
