Add bevy_dylib to force dynamic linking of bevy

[bjorn3]

This easily improve compilation time by 2x.

Fixes #791

TODO

• Mention bevy_dylib in docs.

Tip: You may want to review with git show --color-moved=dimmed-zebra to show moved code grey instead of red+green.

[bjorn3]

Ah, the docs live in a separate repo: https://github.com/bevyengine/bevy-website/blob/master/content/learn/book/getting-started/setup/_index.md

Should I make a PR or should I wait for this PR to be merged?

[cart]

Feel free to make a pr whenever. We'll hold off on merging it until the next release (which will be in about a month) so there's no real time pressure.

[cart]

First: this is super awesome ❤️

I have a proposal for a slight tweak to the crate structure, which allows for a better/clearer UX:

• leave the current bevy crate in the root folder
• add a bevy_internal crate, which pulls all of the crates together / defines the prelude (aka what the bevy crate does on the master branch)
• the bevy crate re-exports the contents of bevy_internal. it also does the use bevy_dylib trick, but only if the dynamic feature is enabled. bevy_dylib would be an optional dependency.

This allows consumers of the bevy crate and examples to just import bevy stuff normally (without worrying about dylib tricks). If they want to force dynamic linking, they just need to do cargo run --features bevy/dynamic (for consumers) or cargo run --features dynamic (for examples). The default cargo run will exclude bevy_dylib from the build tree and build "statically"

I implemented this on my branch here: https://github.com/cart/bevy/tree/bevy_dylib

There are two downsides / caveats:

1. for some reason this breaks imports in our proc macros (but only for examples). i'm trying to fix this now.
2. we need to duplicate feature declarations: once in bevy and once in bevy_internal. i think the extra boilerplate is worth it

If we can fix (1) and you don't find any "gotchas" in this approach, I think I'll just push the changes to this pr's branch.

Thoughts?

[cart]

I think I can fix (1) by making our proc_macro import inference a little smarter. I think using find-crate instead of proc-macro-crate will give me the tools i need.

[bjorn3]

That approach looks better indeed.

[cart]

Wow this plays nicely with the new ECS changes on master. The same example that could iterative compile (with dynamic linking) in 0.59 seconds now compiles in 0.43 seconds.

[joshuajbouw]

Hold up, whats up with all the refactoring when #![cfg_attr(feature = "dynamic", crate_type = "dylib")] could've been used at lib.rs root? Would've accomplished the same thing without the refactor.

[bjorn3]

Cargo passes --crate-type lib, so I don't think #![cfg_attr(feature = "dynamic", crate_type = "dylib")] would work.

[joshuajbouw]

But, that one of the 5 ways that the documentation says will work to change a crate type into dylib.

• --crate-type=dylib
• #![crate_type = "dylib"]
• crate-type = "dylib" in Cargo.toml under [lib]
• rustc -C target-feature=-crt-static foo.rs
• RUSTFLAGS='-C target-feature=-crt-static' cargo build

The first 3 which are essentially the same thing, just overriding each other. Cargo shouldn't pass --crate-type lib by default. Internally a lib is default. Everything else will override it unless you actually pass in --crate-type lib manually.

Also the work done above has the added disadvantage of having to duplicate the module level documentation per crate. It doesn't concatenate I had found out.

So I am not exactly too certain why bevy needs to have it as a feature when you can tell the compiler directly.

[bjorn3]

rustc -C target-feature=-crt-static foo.rs
RUSTFLAGS='-C target-feature=-crt-static' cargo build

These only control if the C standard library is statically linked or dynamically. Dynamically is the default for pretty much everything except musl.

crate-type = "dylib" in Cargo.toml under [lib]

You can't edit the Cargo.toml of dependencies.

So I am not exactly too certain why bevy needs to have it as a feature when you can tell the compiler directly.

The problem is that while you can tell it the compilet directly, you can't tell it cargo directly. When you use cargo, you can't override the crate type of arbitrary crates from your project. You can only set the crate type of your own project, which has to be an executable if you want to actually run your game.

[joshuajbouw]

However, it is important to note that both the crate_type and crate_name attributes have no effect whatsoever when using Cargo, the Rust package manager. Since Cargo is used for the majority of Rust projects, this means real-world uses of crate_type and crate_name are relatively limited.

Just read that from: https://doc.rust-lang.org/beta/rust-by-example/attribute/crate.html. Weird that in their other reference seems to say otherwise. Anyways, yeah, makes sense.