This crate doesn't work for `target = wasm32-unknown-unknown`

[maccesch]

[TGRCdev]

From skimming the PRs, inventory might support WASM, so I'll do some experimentation. If it works, I can make inventory and linkme mutually-exclusive feature flags.

[TGRCdev]

Support for this is almost finished, but I can't seem to solve a specific issue with nested macros like config_systems! and system_set!

Any #[system] invocations that get modified by these macros end up not getting included in inventory's registry. I don't entirely know why, as these just get their attributes modified before being expanded like regular #[system] functions, which would include their inventory::submit! invocations.

[maccesch]

Writing macros can be a pain!

[TGRCdev]

I've been working on a total parsing rewrite on the road-to-1.0 branch. In this, I've tried to make WebAssembly systems work. As it stands, it compiles and it even finishes all the tests on my local machine. But it inexplicably excludes every registered system on the Github Actions test run.

What's there will be included in the 1.0 release, but behind the wasm-experimental flag with a big warning. Hoping that someone with more WASM experience can enlighten me what I'm missing.

[maccesch]

I see. Thanks for all the work!

Are you sure though you want to release a version 1.0 when Bevy hasn't even reached that yet? In the Rust world 1.0 is seen as a serious commitment to stability.

[TGRCdev]

I'm personally pretty happy with the current API, but I think you're right. It might be better to stay in 0.x with Bevy, with the opportunity to iterate the API with feedback.

[dbidwell94]

Just out of curiosity: how much added overhead does this library introduce as opposed to just adding directly in an impl Plugin block? I haven't dug into the source cause I am terrible with writing proc-macros. But it sounds like there's some memory overhead?

[TGRCdev]

Systems, resources, events, etc. are registered using either the linkme or inventory crate depending on your features and platform. I'm not an expert on them, but from what I know these store the entries within the binary's data at compile/link time.

The first time any plugin is registered, it steps through that slice and builds a HashMap from the Plugin's type to a Vec of its butler entries, and stores it in a lazy static.

Generally, a butler entry is created for any invocation of a butler macro, like #[system], #[resource], etc. config_systems! itself is not an entry, but every enclosed butler statement is. system_set! wraps every #[system] into a single entry. The entries themselves are function pointers to closures.

Just from the top of my head, every plugin will have an overhead of 24 + 8e bytes of overhead, where e is the number of entries. This is currently a little underestimated given that we don't trim the Vecs yet (which I should fix...).

tldr;

HashMap<TypeId, Vec<fn(&mut World)>> = 48 bytes
TypeId = 16 bytes
Vec<fn(&mut World)> = 24 bytes
fn(&mut World) = 8 bytes

Approx heap overhead: 48 + (16 + 24)p + 8e bytes

Where p is the number of butler plugins registered, and e is the total number of butler entries across all plugins.

[coolcatcoder]

I don't like self-promoting, but I believe my crate may be useful to you.
Retrieval allows the collection of trait implementations, which is similar to inventory, but more powerful.
It is far from perfect. Currently, both the trait and the iteration function must be defined in the user's crate, rather than the library's, but you can easily hide this behind a setup!() macro or some similar mechanism.
The way it works is not reliant on any target specific machinations.