Test high DPI attribute #45
Conversation
|
Appveyor is broken and doesn't produce binaries. |
|
I'm taking a look at the AppVeyor builds. Most likely, I will need to update the version of Qt being referenced, as the current one may have been removed.
|
|
|
|
Why don't you migrate to vcpkg for appveyor? Qt is already present there too https://www.appveyor.com/docs/windows-images-software/#qt |
|
Welp, Xenial has Qt 5.5. It's not worth doing this, just ifdef it out if Qt < 5.6. |
|
Didn't realize they added Xenial. Shame it isn't modern enough for this PR, though. I'll do some tests with it. (I usually test CI changes in another repo to prevent clobbering this one with repeated commits). Is there any reason we need to support Xenial (or similarly-dated releases) of Linux? (What does OpenRCT2 set as the minimum?) Using the Docker method might make sense if it means working with a more modern version of Qt. Relatedly, apparently AppVeyor now has Xenial and Bionic build environments, so it might make sense to switch it. I'm just not sure which would be better for this. The builds are still failing on the Linux x86 build. This has been one that I've had a lot of trouble with. Since Qt is not in the Multilib list, I've had to do it by installing the :i386 version explicitly, which results in a ton of complications and failures. I don't know if Docker could help with that, but if it can, then it would be worth it to setup just for that. As for using vcpkg for Windows builds, there's no point. AppVeyor environments comes with Qt pre-installed from Qt's website. vcpkg would compile it from source every time (minus caching), which would waste time for no real good reason. I've found that using Qt's official builds works best, to the point where I wrote a script to fetch it for the macOS builds after running into problems with Homebrew. The only reason I'm not using it for the Linux builds is because it affects how zlib is being linked (though I might be able to override that). |
|
There's no explicit minimum system version for OpenRCT2, we only list the
required packages and their versions. It happens that 18.04 (Bionic, LTS)
has all we need and we use that to build, so I'd say it makes sense to
migrate your project to Bionic as well. But that's outside of scope for
this PR.
I suggested vcpkg as I was under impression you were using some more
libraries other than Qt, especially on Windows, or was I mistaken?
|
You're mistaken for the most part. The only non-Qt dependency is zlib, which is included in the Windows build of QtCore. I had looked into using other libraries, namely for ZIP and TAR support, but ended up writing my own code to handle it to avoid this sort of issue. (Also Qt projects are extremely difficult to handle external libraries with. If I were using CMake (which I might switch to), then it would be a different story) |
|
AppVeyor seems to fail on OpenSSL though? What do you need zlib for
and why can't you use the same that Qt already uses?
|
It's a regression due to AppVeyor changing their policy on artifact retention. See #46 for work on the fix, as well as an explanation for why I initially did it the way I did.
I mentioned having my own code for ZIP and TAR archives. The challenge is that the releases use DEFLATE to some extent (either within the ZIP archive, or as a GZ compressed TAR archive), so zlib is used to decompress the data.
Qt can be built in two forms: either with an internal or external zlib. Windows uses an internal zlib by default (and in the vast majority of builds), which this project uses. macOS uses the external zlib provided by apple by default, so this project links against it explicitly. Linux is a bit of a mixed bag, as the "official" release uses an internal zlib, but most version provided by a package manager (ex. apt) uses an external zlib though the package manager. If the build is done with Qt configured with an internal zlib, the resulting binary won't attempt to link against an external zlib, and will result in load-time errors. The same happens in reverse, but it's easier to tell users to install zlib than it is to get them to install the "official" Qt build (or build it from source with the config option). |
No idea if it'll work, just for test now.