Comments (17)
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.
from sadm.
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.
from sadm.
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.
from sadm.
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.
from sadm.
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.
from sadm.
Wouldn't Dolphin linking to a SteamStuff.dll
which links to the Steamworks SDK also cause a GPL violation?
from sadm.
I have no clue, but the point stands even if it needs to be SteamStuff.exe instead of a dll.
from sadm.
This also goes for at least the release windows steam builder. I’m not sure about macOS but I assume the same thing there.
from sadm.
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?
from sadm.
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.
from sadm.
Or if space is a concern, we could do some fancy thing which strips the steam stuff out on demand.
from sadm.
No it is time which I’m concerned about
from sadm.
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
from sadm.
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.
from sadm.
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 🙂
from sadm.
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.
from sadm.
All builders removed.
from sadm.
Related Issues (20)
- msbuild: use native x64 toolchain HOT 1
- Generated .app file is not capitalized HOT 1
- run windows unittests HOT 1
- windows debug unittests take an excessive amount of time
- Git Tags and Tarballs HOT 4
- Add FifoCI results submission API
- Nixify FifoCI mesa worker
- Nixify FifoCI backend service / web UI
- Secure the Central<->Buildbot change submission path HOT 1
- Deprecate old changes poller
- Nixify Buildbot master HOT 1
- Duplicate buildbot releases causing hash failures HOT 5
- Android updater fails to promote build to production track if artifact was already uploaded HOT 1
- Text-based config for dnsmasq is deprecated
- GitHub and buildbot show conflicting PR status HOT 1
- obsolete windows buildbot steps HOT 3
- use multithreaded 7z HOT 3
- symstore improvements HOT 9
- Let's Encrypt automation HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sadm.