[Feature Request]: Qt5 build #5561
Comments
|
PCSX2 is not like those other emulators, perhaps they haven't had time to upgrade or didn't want to bother. Anyway Qt6 will be mandatory. |
|
Well could you outline what exactly is not like those other emulators means? Yes PCSX2 is really late if it comes to Qt support at all but as long as all other major emulation platforms use Qt5 so I don't see any reason why Qt6 should be mandatory at all. Beside that Qt5 & Qt6 should be quite compatible because other projects just check for both versions. https://github.com/mmatyas/pegasus-frontend/blob/master/cmake/PegasusQtUtils.cmake#L10-L13 @stenzek any hints why the build fails with Qt5? |
|
I meant as in they started in Qt 5 which means that they have to revise it to be Qt 6 compatible where-as PCSX2 went straight into Qt 6 to avoid this conversion proces. Stenzek could give you more details on why Qt 6 is chosen and not Qt 5. |
Lastly, why are you expecting us to create a bunch of maintenance burden when Linux is a fraction of the total userbase (probably less than 5%), and users that don't use the AppImage are an even tinier? If you want to step up and maintain a Qt5 build, then sure, go ahead. But don't expect us to do it for you. |
This is also complete garbage. I did a Qt6 build on Ubuntu 18.04 so it could be eventually used for the appimages, and aside from having to upgrade the compiler and cmake, it worked perfectly fine. Don't make statements like that when you clearly have no idea what you're talking about. As for cross-compiling, generally speaking, you need a sysroot to cross-compile. PCSX2 would definitely need one. But it's a moot point regardless, because Qt6 doesn't support 32-bit x86, so PCSX2-Qt is 64-bit only, and there's no need to cross-compile in the first place. |
|
Qt6 will be in Ubuntu 22.04 LTS, so no problem https://packages.ubuntu.com/search?keywords=qt6&searchon=names&suite=jammy§ion=all |
That doesn't help us. Our appimage builder is stuck on 18.04, and if we switch it to 22.04, because appimages are stupid and rely on the system libc, people with older distros won't be able to run them. |
Well I have the strong impression that you didn't got at all what I'm talking about. You talk about downloading the Qt6 source, compiling it with your Ubuntu 18.04 toolchain, building PCSX2 and done. You also assume I'm downloading some precompiled, outdated deb packages and nag about problems compiling against it. Btw. you should already have some insights how I build my PCSX2 package since I've linked you in an issue when your commits broke PCSX2 as in #5226 (comment) I'm talking about using ANY distribution, building a completely independent toolchain (gcc, cmake, glibc, etc.) with the tools provided by the distro and then use this new toolchain to compile a whole disto image for a target arch like arm or aarch64. And instead of asking for details you make bold assumptions and jump to conclusions without even knowing what I exactly meant just to tell me I'm stupid. Thank you very much. I'm btw not the only one who ran into trouble https://forum.qt.io/topic/126645/qt6-cross-compile-experience because of the buildsystem changes. But I see you're focused on Windows as platform & probably don't care that much about other targets which is fine. If you have an independent toolchain it's not enough to compile some build tools (e.g. qmake) as before you need to deploy a whole Qt6 build for build and then CMake uses it to create the target build but this also means you need to satisfy all dependencies for your host toolchain which is just plain nonsense for any build focusing on a target system. I was asking if there is any specfic, technical reason to use Qt6 and why it's mandatory. Ubuntu 18.04 uses Qt5 5.9.5 but I'm talking about 5.15.y which IIRC even has compat modules for the Qt6 transition. Since you most likely link static against Qt it also should not matter if you depend on a newer version which isn't shipped by a dated Ubuntu distro. So it's probably correct that some old packages have been broken repair but again that's not what I was talking about. All in all thanks for the clarification, I got my answers. |
I don't care about packages in nonstandard environments. If it breaks in Ubuntu (or our appimage), I'm happy to look at it, but otherwise it's not my problem. Otherwise, if you want to change stuff and it causes things to break, that's your problem not mine.
And how is this relevant to PCSX2? PCSX2-Qt only builds and runs on 64-bit x86. Are you seriously arguing that we should be concerned about compiling x86 on an arm64 host?
We're making use of the new DPI scaling options in Qt6 for one, and other things like If you want to maintain Qt5 support, go ahead. But don't expect us to do it for you.
hidpi is completely broken in 5.9.5.
That was my initial plan. Unfortunately nothing works properly in Linux, as usual. I built Qt on 18.04, but the Qt libraries link against some float-support library which doesn't exist on 20.04, as well as an older version of libicu. So you can only have one, not the other. Hence why I just shelved and said someone who actually uses the OS can sort it out. If you have a solution, I'd love to hear it, but it's not something I'm going to personally spend any more time on, since I don't use the OS. |
No clue what's a standard Linux environment is but I guess there's reason why you ship precompiled stuff as appimage. IMHO the spirit of OSS is compile yourself & it should run as long as requirements are met & dependencies satisfied. It's not broken because of a non-standard Linux it's broken because of the memsets.
You got the topic? Qt? PCSX2 is not the only application which uses it, there are plenty of tools which depend on Qt and run fine on ARM like Skyscraper, Moonlight-Qt, Pegasus-Frontend etc. so yes there are people who need to cross compile Qt for an other arch & this is complete crap if you have to depend on Qt6 if you're building anything else than just a single app.
This is basically the answer I was waiting for because that's a real reason.
Well beside the fact that it's a pain in the a.. to compile Qt I've never had trouble to build Dolphin, Citra, Yuzu, RPCS3, Pegasus-Frontend, Skyscraper, Retroarch, Moonlight-Qt, mupen64plus-gui (...) once Qt was up and running even though all packages are pretty much bleeding edge but that's nothing special compared to Arch Linux.
It's fine if you don't use Linux. Then just tell people that you don't use it & that you use Qt6 on Windows and that you don't bother to waste time on something you won't use anyway. Because then I wouldn't have had asked for any Qt5 support in the first place. |
The spirit of OSS is also that others can contribute. So far you're just complaining, expecting us to do work and not contributing anything positive.
So? PCSX2 is x86 only, so it's still a moot point. Besides, I read the topic, so what if you have to compile the host tools? It takes a couple of minutes, cross-compiling Qt on windows has always required host tools and it's never been a problem. As someone who's used Qt through 4-6, CMake is a much better build system than QMake.
Then how is it relevant to us? If we're having to use a non-distro build, then we may as well use Qt6 on our builders.
Uhh, it's really not. You run configure and then ninja. https://doc.qt.io/qt-6/linux-building.html
This is PCSX2, not anything else, stop making pointless comparisons. The PCSX2 team is happy with the direction I've taken with the Qt interface, so what you or others think is completely irrelevant. Like I said above, if you want to maintain Qt5, go nuts, but stop complaining and expecting that we do something we're not interested in/see any benefit in doing. Besides, those emus will also move to Qt6 eventually. We have a clean slate and it would be silly to start with Qt5, only to generate a shitstorm when we eventually move to 6. I'm unsubscribing myself from this issue, because this whole discussion is a waste of time. |
Yeah well I guess that's the reason why I've got a contributor flag.
No you have to build a whole Qt6 build for host & then for target which means you need to meet all dependencies for the host toolchain which normally just consists of the usual build tools and not graphic, audio or any other support lib.
Qt5 5.15.y is LTS, still supported and maintained. It just works.
Yes if you use Ubuntu and build Qt6 for your Ubuntu and link PCSX2 static. This doesn't work if you have an independent toolchain which will build a distro for any indepentend target. I guess the link I supplied was clear about that, obviously it wasn't. The toolchain consists of
Well it was a question if it's possible. Nothing more, nothing less. A simple line like
would have been enough. Also if you don't know the specific reason why someone ask maybe don't rant just ask why he asks for this support / option.
Yes the shitstorm... I guess the average user who uses a static linked build appimage won't complain & does not care at all which Qt version is used.
Well if you feel ranting is a waste time - I second that! All I wanted to know was if it's possible to fix the error above which might allows to compile against Qt5, the reason why I would like to have this option should be clear. If you don't care about Linux and Qt5 that's fine but please don't assume everyone is plain stupid just because he asks for a usecase / environment which you're not interested in. |
I mean it is not a problem for those, who want to build pcsx2-qt from source |
Description
I was wondering if Qt6 is mandatory & if it's also possible to use Qt5 for the gui. I made some small changes as in SupervisedThinking@73ec407 to see if I can start to build but it fails with:
Reason
Qt5 5.15.2 is still well maintained, see https://community.kde.org/Qt5PatchCollection, and will receive standard support at least until 05/2023
The build system of Qt6 fundamentally changed and it's bassically impossible to cross compile it for certain projects since it relies on a complete build for host to create a target build while Qt5 only builds necessary tools and can be compiled for the target. This means if you want to support OpenGL on target you have to build mesa and all dependencies on you build(host) toolchain first which is complete utter 💩
Examples
RPCS3, Citra, Yuzu, Dolphin, et al use Qt5 for their frontend.
The text was updated successfully, but these errors were encountered: