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.
Since cbindgen strips the module name, we ended up with an RGB8 type and the RGB8 (and alpha) variants
in the generated code, which made the SharedImageBuffer
constructor ambiguous.
That's not needed anymore now that we use RGB8Pixel and RGBA8Pixel.
That's all it is nowadays, it's a wrapper around Rc<Window>. It's not an
alias because we need to also "wrap" it to C++ via cbindgen, but that's
about it.
If we were to add `sixtyfps:🪟:Window` to the re_exports, then
this clashes. We might rename the former, but this is a cleaner naming
in any case.
Relates to #333
Make sure to never export the Value enum. It might drag in all sorts of
unrelated types (as it happened in #311). We have ValueOpaque for that,
so exclude Value from the export config explicitly. However since we
expose the Value *pointers* for the struct iterators, at least provide a
forward declaration.
Move those two classes into the private_api namespace, which is excluded
from the API reference documentation.
For generate code the explicit qualification of Property<T> is changed,
for the cbindgen generated item types the private_api namespace is
pulled into the cbindgen_private namespace.
