search

LRFLEW / OpenRCT2Launcher

An Open Source Launcher & Updater for OpenRCT2
MIT License
200 stars 20 forks source link

Test high DPI attribute #45

Open janisozaur opened 5 years ago

janisozaur commented 5 years ago

No idea if it'll work, just for test now.

janisozaur commented 5 years ago

Appveyor is broken and doesn't produce binaries.

LRFLEW commented 5 years ago

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.

Qt::AA_EnableHighDpiScaling requires Qt 5.6. This isn't a problem for Windows or macOS, but the Linux Travis builds will need some attention. It currently uses the version from the Ubuntu package manager, but since Travis is stuck on Trusty, this limits the version of Qt. IIRC, we ran into this issue with OpenRCT2, and uses Docker to solve this. I would like it if you helped doing the same for this project. If you can get the 32-bit builds to work better, that would be a huge bonus, as the current method constantly breaks.

janisozaur commented 5 years ago

dist: xenial https://blog.travis-ci.com/2018-11-08-xenial-release

janisozaur commented 5 years ago

Why don't you migrate to vcpkg for appveyor? Qt is already present there too https://www.appveyor.com/docs/windows-images-software/#qt

janisozaur commented 5 years ago

Welp, Xenial has Qt 5.5. It's not worth doing this, just ifdef it out if Qt < 5.6.

LRFLEW commented 5 years ago

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).

janisozaur commented 5 years ago

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?

LRFLEW commented 5 years ago

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)

janisozaur commented 5 years ago

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?

LRFLEW commented 5 years ago

AppVeyor seems to fail on OpenSSL though?

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.

What do you need zlib for?

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.

Why can't you use the same that Qt already uses?

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).