Add information on releasing Bevy games

[alice-i-cecile]

For relative newcomers to Rust, we should start a section on Releasing Bevy games, to go along with our advice on fast compilations.

This should include:

• maximizing the optimization level (Document micro-optimizations that should be done before final game release #4586)
• using relative rather than absolute paths
• how to build executables for different platforms
• eventually, links to concrete advice on releasing the game on various distribution platforms like Steam and itch.io

This information likely deserves its own page, but should be linked on the Bevy website, perhaps near the section on fast compilation.

[alice-i-cecile]

This Bevy game template is another great source of inspiration for tricks to draw from.

[NiklasEi]

* using relative rather than absolute paths

This is about privacy-sensitive paths in the compiled executable, right? Reading through the relevant rust issues (e.g. rust-lang/rust#40552) it does not sound like there is an actual fix or an easy workaround for now. Several people wrote that the mentioned solutions do not work (and I did not see anything about "relative rather than absolute paths").

The way to avoid leaking paths at the moment seems to be not distributing executables compiled on your private machine.

I would propose recommending to only publish builds from CI/CD e.g. GitHub workflows in the new "Releasing Bevy games" section.

[alice-i-cecile]

This is about privacy-sensitive paths in the compiled executable, right?

Correct. I think your proposal is sensible then; it's a shame there's no local machine workaround.

[mockersf]

it's a shame there's no local machine workaround.

Probably building in docker or similar would work... but I would recommend setting up CI anyway

[lberrymage]

Probably building in docker or similar would work... but I would recommend setting up CI anyway

I think CI makes the most sense for most people, but if someone's project isn't open-source, then CI could cost money.

Maybe we should focus on CI on the website, but also link to some documentation on local alternatives like Docker, chroot jails, etc.?

[mockersf]

Just noticed some of our dependencies have licenses that needs to be mentioned when releasing a game made with Bevy. For example wgpu with MPL-2.0
see #2101 (comment) (and #2101 (comment) for wgpu)

[cart]

I just left some thoughts on that here: #2101 (comment)

[mockersf]

We could also consider getting "cute" here by doing something like include_bytes!("uber_license_file") by default (with a way to opt out for people who want slimmer binaries and have other compliance plans), but thats not really in the spirit of these licenses and might not even hold up in court.

The file produced by https://crates.io/crates/cargo-bom for Bevy is 568KB

[cart]

Maybe we can compress it by removing redundant license boilerplate? no clue if that is valid.

[bjorn3]

Another option would be to gzip (or any common method) compress it and add a header that describes in plain text that the following bytes are the gzipped license text. A function to get the license text at runtime could transparently decompress it.

[cart]

I dig that. We could have a bevy_license_compliance plugin that include_bytes!() the gzipped license, adds support for a command line: --print-bevy-licenses argument, and provides a function to get the full text at runtime.

[cart]

And then (depending on the size) we could include it by default.

[Bekreth]

I've been starting to do a bit of poking around on this topic and could use some advice. I'm fairly new to Bevy (and machine languages more generally) and been struggling to make a Debian package file for my example application. When I build the application, I'm unable to directly run the binary due to missing shared libraries. Is the entire target/release/deps folder required in the linker path in order to run the Bevy app? Is there existing best practice on how to bundle up all of these shared libraries? Can some of these dynamically linked libraries be statically linked instead?