Updated 'Enable Fast Compiles' section #137
Conversation
|
|
||
| * **Enable Bevy's Dynamic Linking Feature**: This is the biggest iterative compilation time win and requires no special setup. When you have `bevy` as a dependency you can run your app with dynamic linking like this: | ||
| * **Bevy's Dynamic Linking Feature**: This is the biggest iterative compilation time win and requires no special setup. When you have `bevy` as a dependency you can run your app with dynamic linking like this: |
There was a problem hiding this comment.
This should probably also mention that this feature doesn't always work on Windows.
At least it doesn't when you also use the Zshare-generics config: bevyengine/bevy#1126 (comment)
There was a problem hiding this comment.
Lets make sure we close #131 if you make this change.
There was a problem hiding this comment.
I think it probably makes sense to add this to the "configure cargo" section instead of to the "dynamic linking" section, just to keep the dynamic linking section simple.
There was a problem hiding this comment.
Thanks! I believe my recent changes resolves this.
|
This looks good to me! Once we add the "windows + dynamic linking + share generics" stipulation i think its good to go. |
|
I've looked into this a bit closer and tested it on my Windows machine in an attempt to come up with an as simple solution as possible for people who follow the guide. I made a pull request to turn off the "share generics" option in the config.toml for Windows users, since it doesn't seem to work (bevyengine/bevy#2016). This removes the need to mention this in the actual guide since that file should then work for every OS. "Share generics" doesn't work on Windows, so the only gains to get for Windows users are the LLD linker, bevy/dynamic, and any optimizations nightly brings. bevy/dynamic doesn't work without the config.toml file containing the setting that turns off "share generics", and that option requires nightly to be used. So my conclusion is that as a Windows user you might as well follow the entire guide. So the only changes I've made to the guide is to add a note for windows users at the top saying they need to follow the numbered steps for bevy/dynamic to work, and I've noted where some something is different for Windows users. |
|
Thanks cart and MinerSebas! I believe this is ready for another look! |
| * **Enable Bevy's Dynamic Linking Feature**: This is the biggest iterative compilation time win and requires no special setup. When you have `bevy` as a dependency you can run your app with dynamic linking like this: | ||
| If you're using Windows, Bevy's dynamic linking feature won't work unless you've followed the three extra steps below first. | ||
|
|
||
| * **Bevy's Dynamic Linking Feature**: This is the biggest iterative compilation time win and requires no special setup unless you use Windows. When you have `bevy` as a dependency you can run your app with dynamic linking like this: |
There was a problem hiding this comment.
Does this actually require special setup on windows? Shouldn't it work with the default setup? If this is just a reference to the "share generics" issue, we should just cover that in the "fast compiles configuration section", either by removing it like you did in your pr or by documenting the weirdness / potential errors in the fast compiles section.
I'd prefer it if the "dynamic linking" section was "simple and asterisk free"
There was a problem hiding this comment.
tl;dr: My understanding is that the problem is the share-generics issue. It seems like share-generics are on by default in debug compilation, so that's why it doesn't work on Windows without special setup.
I did some more testing to make sure if special setup is required, and in my tests I run into some variation of the errors linked in #131 when running with --features bevy/dynamic on Windows unless I run with..
Option 1
rustflags = ["-Zshare-generics=n"]- Nightly (required because of the -Z flag in rustflags)
Option 2
--release
Like you write, share-generics is off by default, but only with --release, otherwise it's apparently on by default. This is where I got this information rust-lang/rust#67276 and I've verified it on my machine by successfully doing cargo +stable run --features bevy/dynamic --release with no config.toml file. Incremental compiles with --features bevy/dynamic --release is slower for me than building in debug without bevy/dynamic.
So, following option 1, with nightly and the config file you've already followed 2 of the 3 "advanced" points, so you might as well do the remaining step of using LLD as well. If nothing else, just to keep the instructions simple.
I also want to keep these instructions as simple as possible, and it sucks to have the extra info for Windows users. But it seems to me like bevy/dynamic simply does not work on Windows unless you at least compile on nightly and with rustflags = ["-Zshare-generics=n"].
I thought the share-generics was an opt-in nightly thing, but yeah, I don't know.
I want to add that I don't know what I'm actually doing here, so take anything I present with a grain of salt. I'm just working off my own tests, some Internet searching, a lot of assumptions and no prior experience with Rust nightly or config.toml files. So thanks for probing to make sure this documentation becomes as good as possible! :)
There was a problem hiding this comment.
Thanks for the breakdown! I'll run a few tests on my machine just to get a feel for the various permutations / see if these behaviors are reproducible.
It does sound like we'll probably need to roll with the approach in this pr 😄
|
This should be rebased on top of #154 in the |
|
@alice-i-cecile just so I don't do anything wrong, I should at this time rebase this PR's branch (https://github.com/lukors/bevy-website/tree/patch-1) onto your branch (https://github.com/alice-i-cecile/bevy-website/tree/book-setup)? Including moving the changes in this PR to where they should be in the new book etc. Won't that include all your changes into this PR? Or maybe that's fine? |
|
@alice-i-cecile I couldn't figure out how to preserve the history of my commits, so I just put the changes in a new commit on top of the branch and force pushed. Also made sure formatting looked good after going through Zola and did some other minor improvements. I hope this is ok and I did it right? |
Yep, that's totally fine here :) Thanks! It looks like you need to change which branch you're making the PR to though; this is still targeting |
|
Great! :) Ah ok, I think I did that now. |
|
A merge conflict appeared for some reason when #154 was merged. I fixed it, so this is ready on my end. As a reminder for cart, this is what you wrote about it most recently, so you don't forget to run those tests:
If anyone else wants to test it that would be great as well! AFAIK I'm the only one who's checked thoroughly, so would be nice to make sure it's all good before it is merged. |
cart
force-pushed
the
new-book
branch
2 times, most recently
from
04bc036 to
477268e
Compare
It seems like this option needs to be off on Windows: bevyengine/bevy-website#131 This change also simplifies the instructions required for the Fast Compiles section of the book: bevyengine/bevy-website#137
I did so. Results here: bevyengine/bevy#2016 (comment) |
|
@SevenO2 Great news! Thanks a lot! 😄 Looks like some conflicts have popped up, I'll fix these soon, and then hopefully this will be ready to merge! |
It seems like this option needs to be off on Windows: bevyengine/bevy-website#131 This change also simplifies the instructions required for the Fast Compiles section of the book: bevyengine/bevy-website#137
|
I merged this on top of the new-book branch. I'm assuming that's what I was supposed to do, but please let me know if that's wrong. :) I also want to add that I'm not 100% confident that I merged it correctly. I think I did, but I very rarely do these types of merges so I'm not sure. I guess this is ready to be merged again if all is looking good! |
Yes please; that's the most useful spot for it right now. Hopefully we can merge in #176 soon, and then rebase this on that. |
| ```sh | ||
| # Install the nightly toolchain | ||
| rustup toolchain install nightly | ||
| # EITHER configure your current project to use nightly (run this mmand within the project) |
There was a problem hiding this comment.
Yeah it's a typo, should be "command", fixed and thanks! :D
| rustup default nightly | ||
| ``` | ||
|
|
||
| You can use `cargo +nightly ...` if you don't want to change the default to nightly. |
There was a problem hiding this comment.
| You can use `cargo +nightly ...` if you don't want to change the default to nightly. | |
| You can use `cargo +nightly ...` if you don't want to change the default to nightly but just want to use it once for the current command. |
There was a problem hiding this comment.
This is a good addition, added, thanks! :D
|
I've incorporated the body of this PR into #176 with credit <3 It will probably be simpler just to merge that, if you're alright with that. |
|
@alice-i-cecile Yeah that works for me, thanks! :D Should I close this PR now then? :) |
|
Yep; we'll close this down and give you credit in the release notes! |
I found this section a bit confusing and ran into some issues when I tried following it. So my goal with this PR is to make it clearer and less error prone.
sudo apt-get installfor Ubuntu as it was required for me on Pop!_OS 20.10 (based on Ubuntu 20.10).