Move to Buildstream

[julianrichen]

Opening a new ticket even though this is similar to #12. While the general idea of moving to that design was good using a Flatpak manifest wasn't. In testing I've done locally building with Buildstream has already been much better for builds. Better build times and especially subsequent build times as most artifacts are saved and you're only rebuilding what you need. You can also inherit a lot from the freedesktop-sdk with junctions.

• [x] x86_64 builds (stable base winehq versions)
• [x] i386 Compat builds (stable base winehq versions)
• [x] Install Wine binaries into lib/{arch}/wine/bin and sym-link to bin/ so x86_64 SDK can run Compat.i386 binaries
• [ ] Setup proper $PATH
• [ ] Add extension points
  • [ ] Geko
  • [ ] Mono
  • [ ] Extensions (corefonts, d3dx9, dxvk, vcrun20xx)
  • [ ] Wine (Other wine versions like staging & proton. e.g. org.winepak.Platform.Wine.5-10-staging)
  • [ ] Wine Compat (Other wine version in 32bit. e.g. org.winepak.Platform.Wine.5-10-staging.Compat.i386)
• [ ] GPG sign builds

[ramcq]

Hi @julianrichen - would it make sense to set up a call together with some Flathub folks? I think we can figure out a path forward that lets Wine be built / maintained on the Flathub infrastructure and then opens the way for app wrapper Flatpaks to be submitted by multiple people. There are also some differing opinions about whether Wine makes more sense as a runtime vs a base app - maybe we could talk through?

[julianrichen]

Hi @ramcq, I think that would be a good idea. I sent you an email to discuss further.