Remove *-steam-* builders ? about sadm

[shuffle2]

The steam target is similar to the Uwp xbox one (in development in a pr): the only difference is in deciding which binaries to include in the output package, and how to package them. However, the core dolphin code base is identical and will in fact compile to identical binaries. So by adding new workers for each of these targets, the build times scale linearly while the unique outputs differ only marginally. It’s just a very bad waste of time and resources. Additionally it turns code maintenance into spaghetti when it doesn’t need to be (and when developing locally you shouldn’t need to rebuild everything just to target steam or Xbox, either).

Basically, these problems should be handled by the build systems and packaging tools, and not by multiplying the entire pipeline.

[delroth]

For now there isn't much difference, but we definitely expect more in the future as we start integrating with stuff like steamworks. I'll let OatmealDome give a more authoritative answer though.

[shuffle2]

Does it actually need a different build tho? Hopefully it can be runtime-dynamic and not a build configuration.

To rephrase that a little: please do everything possible to make it not a build-time configuration.

[OatmealDome]

I'd like to keep this builder if possible.

Does it actually need a different build tho? Hopefully it can be runtime-dynamic and not a build configuration.

My plan for Steamworks integration involves creating a separate executable that powers the integrations for us. We can't integrate it directly because linking with the SDK would cause a GPL violation. (Similar solutions include icculus's steamshim and RetroArch's mist.) This executable shouldn't be built and included on the normal builds, so I was hoping I could lock it behind the Steam msbuild property.

Is this builder really helpful?

Because I don't primarily develop on Windows, I was going to use pr-steam-win-x64 to make sure those future PRs build properly.

[shuffle2]

Does it actually need a different build tho? Hopefully it can be runtime-dynamic and not a build configuration.

My plan for Steamworks integration involves creating a separate executable that powers the integrations for us. We can't integrate it directly because linking with the SDK would cause a GPL violation. (Similar solutions include icculus's steamshim and RetroArch's mist.) This executable shouldn't be built and included on the normal builds, so I was hoping I could lock it behind the Steam msbuild property.

I don't think this prevents my goal of keeping the "Steam stuff" in the normal build. We can always build your "SteamStuff.dll", and it will only actually function if whatever Steam APIs are actually found, dynamically.

Rebuilding the entire dolphin source tree when it's 99% the same code just doesn't seem like a good use of resources. And IMO, keeping it runtime-dynamic will just make the code cleaner and easier to reason about, anyway.

[OatmealDome]

Wouldn't Dolphin linking to a SteamStuff.dll which links to the Steamworks SDK also cause a GPL violation?

[shuffle2]

I have no clue, but the point stands even if it needs to be SteamStuff.exe instead of a dll.

[shuffle2]

This also goes for at least the release windows steam builder. I’m not sure about macOS but I assume the same thing there.

[Zopolis4]

Is there a problem having these builders? Like if they were causing a space issue or something sure, but as it stands I don't see any actual issue with them. And if they cause no issue but will lead to a cleaner experience for the end user (not having an unnecessary executable), then why not keep them?

[Zopolis4]

We could probably find a compromise by building the steam stuff, then not shipping it for non-steam builds, so having one builder that provides 2 outputs.

[Zopolis4]

Or if space is a concern, we could do some fancy thing which strips the steam stuff out on demand.

[shuffle2]

No it is time which I’m concerned about

[Zopolis4]

First one would deal with time, second one would probably be good long term. Just because we have the resources to burn doesnt mean we should burn them :p

[delroth]

There's nothing being "burned", idle build workers cost us the same as busy build workers. IMO the only argument we should look at is whether compile-time vs runtime gated Steam integration is better, what that means for Buildbot usage bears very little importance.

[shuffle2]

Waiting for builders is extremely annoying to me (and so is waiting for my prs to sit in the queue for months these days), but i guess that’s just how it is now.

but I think the fact that it impacts local development is also annoying ans leads to worse code. You should not need to rebuild the entire project as if you’re building for a different architecture just to target steam or Xbox. It’s just…bad 🙂

[delroth]

FWIW I don't have a strong opinion either way at this point, assigning to OatmealDome to figure out the long term plan here on how Steam should be handled, feel free to discuss that together and let me know in the end if you keep or don't keep a separate build configuration for this.

[OatmealDome]

All builders removed.