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 . 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
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
- 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: