Legacy OS X build changes

[cme]

Changes to allow building with a legacy Mac OS X system (Yosemite, OS X 10.10) with Qt 5.9.9, to support old systems.

It might be possible to configure this in an Appveyor VM, but for the moment works fine on a Yosemite VM.

[theGreatWhiteShark]

It might be possible to configure this in an Appveyor VM, but for the moment works fine on a Yosemite VM.

The main problem I had with AppVeyor was that pacman just works with the most recent Visual Studio version. But older Qt versions are only preinstalled in the previous Visual Studio version :/ . Our code itself was fairly easy to adopt.

[cme]

The main problem I had with AppVeyor was that pacman just works with the most recent Visual Studio version. But older Qt versions are only preinstalled in the previous Visual Studio version :/ . Our code itself was fairly easy to adopt.

Do you know if it would be possible to use recent VS versions to build a legacy Windows binary?

I've been wondering about this because, I've just upgraded my home server hardware to a newer machine that has CPUs with nested page table support and so can run VMs at an entirely respectable pace, which made me think about the macOS builds. The recent builds could only work as far back as 10.12, but there's no real reason we can't stretch back as far as 10.10 with a suitable build host, just not what's available on Appveyor. Dropping support for pre-Mojave macOS in the 'main' builds would clean up the Appveyor builds by removing the need to rebuild some packages for the earlier OSes, and these OSs could still be supported by the legacy release builds.

It doesn't feel right to have an open source project limited by what's available on a cloud provider for binary releases, when we could easily support older machines in the source code base, with the proviso that binary releases for them could be 'second class' and best-effort.

I've also been wondering about how best to make that extra CPU power and VM-ability (it's Apple hardware, so can legally run macOS VMs) available as a resource to the project at-large (possibly via Appveyor's BYOC for faster CI) :)

[theGreatWhiteShark]

Do you know if it would be possible to use recent VS versions to build a legacy Windows binary?

I think so. The only reason I've used the previous VS version was because AppVeyor preinstalled a Qt version which could in theory still support Windows XP. For the recent VS version a matching Qt needs to be build from source (and I guess we won't do that in each run of the CI 😄 )

I've been wondering about this because, I've just upgraded my home server hardware to a newer machine that has CPUs with nested page table support and so can run VMs at an entirely respectable pace, which made me think about the macOS builds. The recent builds could only work as far back as 10.12, but there's no real reason we can't stretch back as far as 10.10 with a suitable build host, just not what's available on Appveyor. Dropping support for pre-Mojave macOS in the 'main' builds would clean up the Appveyor builds by removing the need to rebuild some packages for the earlier OSes, and these OSs could still be supported by the legacy release builds.

Awesome.

It doesn't feel right to have an open source project limited by what's available on a cloud provider for binary releases, when we could easily support older machines in the source code base, with the proviso that binary releases for them could be 'second class' and best-effort.

Yes, definitely. As an open source project we could most probably help more people by supporting legacy systems and devices instead of racing for the latest Qt and C++ version. But, on the other hand, we have limited resources too. I also thought at some point about compiling an older Qt version locally and using it to build the legacy XP support manually. But I decided to not do it as it doesn't seems to be feasible over a longer period of time (and I would have to stick to an awfully huge tower PC and keep it's windows up and running).

I've also been wondering about how best to make that extra CPU power and VM-ability (it's Apple hardware, so can legally run macOS VMs) available as a resource to the project at-large (possibly via Appveyor's BYOC for faster CI) :)

That would be really great!

[cme]

Having sat on this for a while, I ended up having to build a new toolchain on the older VM in order to support a newer C++ toolchain than the native XCode provides and finally realised it would just be better to build dependencies entirely outside of Homebrew and provide these as binary releases available to Appveyor anyway.

[theGreatWhiteShark]

provide these as binary releases available to Appveyor anyway.

Are we able to do so in our current AppVeyor setup? Would this also be possible with an old Qt5 version for the Windows build in order to enable XP support?

[cme]

provide these as binary releases available to Appveyor anyway.

Are we able to do so in our current AppVeyor setup? Would this also be possible with an old Qt5 version for the Windows build in order to enable XP support?

My thinking was to create a new repository (or repositories) for collections of explicit depedencies, and small enough that each can be built within the time allowed by appveyor, and binary releases kept on github.

[elpescado]

it would just be better to build dependencies entirely outside of Homebrew and provide these as binary releases available to Appveyor anyway.

I've been thinking about this some time ago. Most dependencies are now cmake-based, that allows them to be built in simple, consistent and cross-platform (Windows!) way. The problem might be sheer amount of dependencies. Despite Hydrogen having few direct dependencies, most of those pull some other dependencies which also need to be built, eg. sndfile requires libogg, libvorbis, libflac etc, libarchive requires zlib, bzip2 etc and qt requires who knows what.

small enough that each can be built within the time allowed by appveyor, and binary releases kept on github.

If AppVeyor becomes bottleneck, Github Actions and Azure Pipelines provide some generous CI offerings.

[cme]

it would just be better to build dependencies entirely outside of Homebrew and provide these as binary releases available to Appveyor anyway.

I've been thinking about this some time ago. Most dependencies are now cmake-based, that allows them to be built in simple, consistent and cross-platform (Windows!) way. The problem might be sheer amount of dependencies. Despite Hydrogen having few direct dependencies, most of those pull some other dependencies which also need to be built, eg. sndfile requires libogg, libvorbis, libflac etc, libarchive requires zlib, bzip2 etc and qt requires who knows what.

Agreed, I've made some progress on this. Some dependencies are ones that can be pruned (for example, Hydrogen's libarchive is only ever used to read/write archives in one format so no extra compression libraries needed), but there's still a lot of them.

Qt I think we should be able to use released distributions from Qt. Without building Qt, everything else should be fairly quick to build even under Appveyor.

JACK is an odd case since building JACK binaries to distribute with Hydrogen is in fact the wrong thing to do (#1287). The largest thing that stopped consideration of WeakJACK instead was the fact that PortAudio, built with JACK support, would expose the same issues, but if we build a PortAudio specifically for Hydrogen, it should only be a small extra step to build that with WeakJACK as well.

So perhaps, if it's painless enough to be able to do it for legacy system builds, it may be worth considering for all CI builds. Hmm.