We can't call return-if-changed with "builtin:" URL, otherwise cargo
thinks the build script always need to be re-run
Fix the gallery example always being rebuilt because it uses AboutSixtyFPS
It does not update the version number in the README because
these are either not part of the versionized documentation
or the demantic versioning make it work anyway
This requires some gymnastics to get right as the information
need to be passed to the compiler despite having no direct dependency
between the compiler and the runtime or backends.
So use a file in the build directory to tell the default style
cc: #83
We need to embed resources in wasm builds. Unfortunately we can't detect
that we're called by say wasm-pack and "TARGET"/"HOST" only works inside
build.rs. So instead, to keep things simple, this change always embeds
the image resources when targeting Rust.
The `SIXTYFPS_EMBED_RESOURCES` environment variable can be used to
override this anywhere for any language.
Fixes#130
Don't expose the internal type but create a public wrapper with the
builder pattern. That makes it easier to change defaults and it hides
internals like the callback futures.
When referencing an image a repeated element and were targeting a
configuration that requires resource embedding, then that image would
not embedded.
This was due to the fact that we didn't recurse into sub-components in
the resource collection phase and the generators made a per-component
embedding decision. The field responsible for that was also not
propagated to sub-components.
This patch addresses these two bugs by cleaning up the entire mechanism:
The compiler first generates the new ResourceReference::AbsolutePath for
all img!"foo.png" expressions. If the compiler is configured to embed
resources, then the embed_resources pass will traverse all
sub-components and expressions in them to change them to
ResourceReference::EmbeddedData with a unique integer id. Simultaenously
all the resources to be embedded get also collected in the root
component, so that the build script as well as the generator can take
care of dependency handling and actual resource embedding.
This will allow the online editor to load imports from URL asynchroniously later
Since currently the compiler is only working on a single thread, and that we
never await on a future that could block, it is allowed to use the spin_on executor
