Add conditional compilation for specific protocols

[Douile]

This allows for conditional compilation at protocol level (although most games are valve anyway :^) ). Changes the behaviour from enabling disable_x feature to disable either services or all protocols to being able to enable specific services and protocols. All protocols and services are put in default so in order to only include a subset default-features=false must be used.

Closes #38

[Douile]

To be honest I'm not sure this is the best way to do it, I don't like how each game import has to have its own cfg.

[cainthebest]

To be honest I'm not sure this is the best way to do it, I don't like how each game import has to have its own cfg.

This is the issue when i looked at it was that there was no nice way of doing it, i have thought about grouping games but then its bloated. eg with this you have the feature valve_protocol but the user of the lib may only need 1 game to query so there is a remainder of unused code.

[Douile]

The problem is you can't generate features in a build script because i don't think they cant change Cargo.toml. Any automated solution I can think of to this would need code generation which is complicated 😔.

A better solution might be:

• script (CI) generates feature list and adds to cargo.toml, while working out dependencies on protocols.
• a macro that generates the conditional include based on game name so that they are each one line.

Alternatively the entire of games/mod.rs could be generated by a build script.

Im not sure which if any of these would be most user friendly and not block #36

[cainthebest]

The problem is you can't generate features in a build script because i don't think they cant change Cargo.toml. Any automated solution I can think of to this would need code generation which is complicated 😔.

A better solution might be:

• script (CI) generates feature list and adds to cargo.toml, while working out dependencies on protocols.
• a macro that generates the conditional include based on game name so that they are each one line.

Alternatively the entire of games/mod.rs could be generated by a build script.

Im not sure which if any of these would be most user friendly and not block #36

I do think this may be a good avenue to look into, here's just some additional ideas to help work towards the PR.

1. External configuration file: One approach could be to use an external configuration file to define the desired feature list. This way, we can avoid directly modifying Cargo.toml. During the build process, the build script can read this configuration file and generate the appropriate entries in Cargo.toml.

2. Preprocessor or templating tool: Another option is to leverage a preprocessor or templating tool to generate Cargo.toml dynamically. By using a template, we can define variables and conditionally include or exclude sections based on specific conditions. This way, the build script can generate the necessary Cargo.toml entries during the build process.

3. Dynamic module loading: Instead of generating the entire games/mod.rs file, we can implement dynamic module loading in our code. We can have a base games/mod.rs file and load the appropriate game module dynamically at runtime, based on the specified game name. This way, we can avoid generating the entire file during the build process. Although this doesn't seem developer friendly.

[Douile]

Would using a pre-processor during the build process break builds for crates.io?

[cainthebest]

If you process after publish in the pipeline then yes but I would assume that this would be done pre-published

[Douile]

So we could have a git pre commit hook that regenerates the templated cargo.toml stuff, then verify this ran using CI, and manage the generated files as normal with git. Or would that cause confusion because when changes to games are made other files will automatically change?

[cainthebest]

For simplicity i think the best way would be gh-actions unless it can be done in a build.rs so that its not on the dev to understand the build process

[Douile]

I'm working on automated code generation in #42, after that is added feature flags can be added.