Move the rendering preparation, actual rendering and input processing
callbacks into standalone functions. They don't
really need to be variable parameters.
This is relatively straight-forward via a pass in the compiler to
collect the resources to embed and then use include_bytes! (once per
resource).
What's really annoying is that the rust resource enum can't store a
&'static [u8] because cbindgen doesn't represent that, probably because
the slice representation isn't guaranteed to stay as it is. So instead
this, for now, uses raw pointers.
The Image's source property used to be a string. Now it is a Resource
enum, which can either be None or an absolute file path to the image on
disk. This also replaces the internal Image type.
The compiler internally resolves the img bang expression to a resource
reference, which shall remain just an absolute path. For now the target
generator passes that through, but in the future the target generator
may choose a target specific way of embedding the data and thus
generating a different Resource type in the final code (through
compile_expression in the cpp and rust generator).
The C++ binding is a bit messy as cbindgen doesn't really support
exporting enums that can be constructed on the C++ side. So instead we
use cbindgen to merely export the type internally and only use the tag
from it then. The public API is then a custom Resource type that is
meant to be binary compatible.
By setting RUSTFLAGS in the Cargo config we run into the situation that
when doing a host build, all rust files are compiled with the flags,
including build.rs. When cross-compiling, build.rs is not build with the
RUSTFLAGS specified. That makes kind of sense, but it also means that
all the build scripts are always recompiled when switching between a
target and a host build - and that applies to *all* packages, including
dependencies.
So short of a better solution, this patch removes the need to set
RUSTFLAGS. It was used to extract the system library dependencies for
the static library we'd create. Instead we're now building two shared
libraries and are linking against them. They contain the rust library
twice, so that's not really a desirable final state either, but
productivity wins right now :-)
It might make sense to go back to creating *one* shared library through
a dedicated crate and -- since 'pub extern "C"' functions are not
transitively exported, it may require re-exporting them by hand or using
some clever build trick perhaps.
Based on Olivier's suggestion, the text rendering primitive is created
by painting the text onto a temporary HTML canvas
element and binding that to a texture.
The objective is to automatically create a propery cmake module, with a
FindSixtyFPSConfig.cmake, corresponding targets .cmake files, etc. This
should encapsulate the build profile (debug vs. release) and also allow
making the choice of shared vs. static transparent.
Unfortunately it does not seem to be possible to easily combine different
crates into one cdylib crate that can re-export symbols from the
statically linked rust crates (cbindgen generated, as well as manual
extern "C").
That means for the dynamic case (not cared for right now), we're going
to need to create either one cdylib per crate that has public symbols or
manually re-export the symbols.
For the static case, linking just against the "last crate" in the chain
(the gl renderer backend) is sufficient to pull in all needed symbols.
In addition for the static case we need to specify the linkage of some
external libraries. This can be extracted manually via
cargo rustc -p gl -- --print=native-static-libs
for example. For now that's in the changed CMakeLists.txt, but the plan
going forward is to automate this extraction in an xtask, to paste that
into the cmake target.
Finally, both linkage scenarios require access to the headers. This is
for now solved by generating them simply in an include sub-directory of
the build folder ($root/target/${profile}/include).
Remove the Optional from the evaluation context passing for property
evaluation. Unfortunately there are nullptr uses left on the C++ side,
that need to be replaced with passing through.
