Evaluate cfg-guarding individual extensions

[Ralith]

The number of extensions is stacking up a lot, and any one application won't use most of them. We should investigate how much build time we could save by making them opt-in. A good baseline would be to compare the current build with one that uses only the typical collection of desktop WSI extensions.

[MarijnS95]

Iirc that, together with removing instance and device only netted 0.5s on my machine: #483 (comment)

[Ralith]

If I understand correctly, that comment discusses only the handwritten front-ends ("manual modules"). Have we explored gating all generated code (including e.g. data structures) as well?

[MarijnS95]

I guess most of the win is in generated code, which proved difficult to gate for, for example, the video extension.

We'll need a restructured generator for that (or lots of passing mutable maps around 😂).

[i509VCB]

Considering most projects use a fraction of the extensions, I would hope that we could rely on many smaller extension features.

I guess another thing that could be done is to generate structures provided by extensions in a different files?

WSI and physical_device_properties2 are the most common extensions I see generally.

[Ralith]

For prior art, fine-grained features have been used to good effect to address this problem in winapi and windows-rs.

[i509VCB]

I guess the only confusing issue is that an extension can have a graph of dependencies. Vulkano appears to have done codegen to make that work fine .

[i509VCB]

Another thought, we have hand written wrappers for extensions, would moving those to another crate result in any compile time changes?

Although this won't allow cargo to compile both crates in parallel.

[MarijnS95]

Prior art specifically for Ash, on manual helper structures: #483 (comment)

0.5s win over a ±7.5s build wasn't a whole lot, and some of it caused by disabling entry/instance/device. We should retry that.

---

IMHO this is a nice thing to have. vk.xml already clearly separates (type) definitions from the extension(s) needing them, making it fairly trivial to hide them behind an any() with some generator magic. I'd like to get the refactoring / erupt merge done first though, as this is yet another larger change that'd require a significant mess in there while it is already unbearable.

Just like windows-rs we can use the extension "dependencies" in vk.xml to populate the [features] section, replicating dependencies to make sure things are available as expected.

In my eyes we should then also go the whole way and separate out Vk 1.0/1.1/1.2/1.3 too: not just traits for the manual wrappers, but everything (as discussed before).