Recent searches
Search options
Looking for input on build orchestration for #rustlang applications where we should draw the line of Rust-specific vs more general tooling.
For more background, see https://epage.github.io/blog/2023/08/are-we-gui-build-yet
@epage Hey Ed, nice post! Reads like a writeup of what was discussed during RustNL! I quite enjoy reading back the discussion we had back then. One thing of note; the processing we end up doing on bundles assets actually takes a significant amount of time.
@epage for now we're happy with our fork of xbuild (mostly, see https://github.com/Traverse-Research/xbuild ) because it allows us to set project specific metadata (eg which android capabilities do we require) set up reverse port forwarding to the host, generate & embed the application icons etc
@epage Have you given meson any consideration? I think it’s still quite lacking in Rust support, but it might be a good fit as something higher level than make.
@epage I currently find that whenever I go to a different programming language I always miss the rust project structure:
src/main.rs
src/lib.rs
Languages like Python that don't work OOTB with build tools are annoying (I've heard poetry helps, but 
).
That is usually my main point of friction with such a tool, you should be able to do something like "cargo new" and have a project that builds with no further configuration.
@epage my thoughts would be hooking into the build system present, ie. have a build function that knows that if you have a Cargo.toml at the root you want to run cargo build, unless you specify otherwise in the configuration file.