Explicit Global hubs

[kvark]

Fixes #354

[grovesNL]

What's the reason to move to local instead of remote? I could see usefulness in being able to opt out of remote-specific concepts if we expose more in wgpu-native (even though we don't have much currently). Either way it might still be good to list local as a default feature to make it easier for people to build wgpu-native directly (thinking of https://nest.pijul.com/porky11/wgpu for example)

[kvark]

I think that's a good idea!

[kvark]

The answer is - remote used to add some extra capabilities, like the Serde derives. As I was trying to integrate it into Gecko, I realized that using Gecko's IPC is the only way. That means Serde is no longer useful, or at least, doesn't get associated with "remote" feature.

At the same time, this PR gets rid of the static GLOBAL in general case. So it's "local" that adds features now: it exposes C entry points and declares a lazy static used in them.

[kvark]

Actually, I'm hesitating to make local default :/ Reason being: default features have a tendency to be force-enabled. For example, if there is any wrapper/helper around wgpu-native, we'd need to make sure that it's using "default-features = false".

The inconvenience will not affect wgpu-rs users. It's only going to affect users of wgpu-native from other languages, like the one you linked to. It's a one time fix for them without any unexpected problems down the road.

Saying that, we can always turn this back to default - it's a 2 line fix.
bors r=grovesNL

[bors]

Build succeeded

• continuous-integration/travis-ci/push