Amethyst Feature Gates

(Marco Alka) #1

PR, which brought up the discussion:

I do not want to prevent the PR from being merged, since it is an improvement, so @khionu asked me to open a topic over here.

To sum up the discussion: Feature Gates are a nice way to select what has should be included, and leaving out not-needed parts speeds up the compilation. In this context, I suggested also making the renderer and the input optional, so that things like headless servers and bots could benefit from the same advantages.

Khionu also added that the purpose of the Amethyst crate might play an important role in this discussion. In my opinion, the Amethyst crate is a convenience wrapper over all the different modules. Making the wrapper more dynamic would not change it to an “entry point that everything could use”. It might, however, be important in what way this wrapper can be configured, because stupidly making every single feature available would be no better then making a new crate from every module. That’s why I want to suggest to make the wrapper configurable in a sense that default scenarios are supported. In addition to default, which is available right now, the list could look like this. For quick and dirty prototypes, the wrapper still delivers everything, but there are also groups to quickly set up something common.

# Scenarios:
bench = ["animation", "audio", "gltf", "renderer"]
default = ["animation", "audio", "gltf", "input", "locale", "network", "renderer"]
server = ["gltf", "network"]
# ...

# Or pick w/e you need
animation = [
audio = [
gltf = [
input = [
locale = [
network = [
renderer = [

Unfortunately, I don’t know how much work this would be and if it is useful at all, so I would like to hear your opinions!

1 Like

(Khionu Sybiern) #2

What really matters for this change is what kind of convenience wrapper it is. It it’s intended to be for getting a game setup quick, then these changes make less sense. However, if it’s meant to be general purpose, to keep the noise in a dev’s Cargo.toml, then we would definitely want to have everything but amethyst_core optional.

There is also the issue that we have some basic utilities and glue split between amethyst and amethyst_utils. This should be resolved at the same time.


(Fletcher) #3

Splitting up the amethyst repo is a discussion we are having right now, and how to best go about it. Headless servers are definitely in the must have column.


(Khionu Sybiern) #4

This is more about the crate structure than repo. Headless servers are already feasible, just not using the amethyst crate specifically. This was caused by an understanding that was implicit and potentially misconstrued by multiple people, and in fixing it, we could go in either direction I summarized.


(Fletcher) #5

Same thing…the amethyst/amethyst repo (and its constituent crates) are going to need to be re-organized. Headless servers are made much easier without the input and renderer. We can do it in another PR, though.

@maruru If you want to do a PR putting input and renderer behind a feature gate, ping me and I’ll help with it.

1 Like

(Khionu Sybiern) #6

I mean, if we reach a conclusion quickly, it could be appended to Jojo’s PR. Point of this was just to make sure it didn’t block the PR


(Fletcher) #7

I’ve not tested compilation without input, only without renderer. =) I’d rather Jojo’s PR get merged and we do this as a separate one.


(Joël Lupien) #8

Basically you’ll need to add feature gates in amethyst/src/{a couple of places} inside of the code. For example, you can’t have StateData without having both ui and rendering enabled.

Also, please don’t separate amethyst into multiple repositories. We already had this discussion and it was agreed we would not do it.


(Fletcher) #9

Topics sometimes need to be revisited as circumstances change. I don’t know how long ago this was discussed, but it is something that will be periodically reviewed as we grow. But this is a higher level architecture discussion better suited for a dedicated post later.


(Thomas Schaller) #10

I think the first conclusion from this is that we should add more feature gates?

1 Like