Legion Transition Bi-Weekly Status Update

I would like to use this Topic to discuss the current status of each part that is currently in migration.

For a start let me begin:
I think I migrated the amethyst_tiles accordingly but I am currently sitting on the tiles example to test if everything in amethyst_tiles works correctly.
Hit a roadblock of nested borrows in the example’s systems. But I think I can easily fix them by using World Splitting, already started with that.
Another roadblock was the common used camera and transform fetch code (https://github.com/amethyst/amethyst/blob/master/examples/tiles/main.rs#L197-L202)
I think I have a solution with less boilerplate but I am still experimenting. If someone comes up with a handy version of that snippet that would be appreciated as well.


I’m super-thankful to @valkum for taking the initiative to coordinate this. I thought (and volunteered) to do a bunch of project management for the legion port, but that was a mistake. Project management is a big part of what I do at my day job, and trying to do it here makes my involvement with Amethyst not fun. And I contribute to Amethyst for fun. So I’m officially un-volunteering for that part :stuck_out_tongue_winking_eye: . Kudos to @valkum and anyone else who can move things forward on the project management front.

I am quite happy just sitting down and programming, so here’s my report:

  • I did a second review of @LechintanTudor’s amethyst_core port, and then merged it into legion_v2

  • I helped fill out @mralve’s final tracker issue with relevant details and pinged everyone I could think of before I ran out of project-management steam.

  • It is a huge pain to try to compile individual sub-crates that depend on rendy but don’t have their own vulkan/metal features to pass down to it, and this legion port is being done one sub-crate at a time. So I have been working on making it unnecessary to specify a vulkan/metal feature.

    • My first and second attempts revolved around Cargo’s built-in conditional dependency handling to automatically select the features via special syntax in Cargo.toml. This has the potential to be a great approach, but Cargo unions all the features of the same dependency from all the conditional places it is specified, completely mangling the intent. (Oh, you wanted vulkan AND metal, right? No!!). If they ever stabilize this fix, then this approach may be worth revisiting.
    • My third attempt (I didn’t make a PR) was to investigate @jlowry’s suggestion make use of build.rs to auto-detect and specify the features, but build.rs can’t emit features that can affect dependencies…because the dependencies have already been build before build.rs is run for a crate! This might become a viable approach if Cargo itself is completely refactored to make more than one pass over the dependency tree, but I’m not holding my breath for that one.
    • Remaining possibilities: