Re: [Development] Qt 6 co-installability with Qt 5
Den tis 23 feb. 2021 21:27Joerg Bornemann skrev: > On 2/23/21 8:52 PM, Thiago Macieira wrote: > > On Tuesday, 23 February 2021 00:00:22 PST Joerg Bornemann wrote: > >> On 2/20/21 2:44 AM, Thiago Macieira wrote: > >>> Besides, doesn't Windows now have symlinks? > >> > >> For admin users only unless an admin user enables them for everyone. > >> Hard-links are available though on NTFS. > > > > Can we use the hard-links then? > > CMake supports creating hard links with file(CREATE_LINK). > > "cmake --install" does not directly support creating hard links. One > would probably have to use install(SCRIPT) with a script that runs > file(CREATE_LINK). > > For the installer, 7zip supports storing hard links since 9.33. > > Without trying anything, it looks like using hard links could work. > I guess it rules out installing to e.g. a FAT-formatted USB-stick, but I don't know if that's a thing. Could be considered an edge case and documented not to work. Elvis > > Cheers, > > Joerg > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] The sorry state of the Qt6 cross compile experience
Hi, On 23/2/21 9:27 PM, BogDan Vatra via Development wrote: - IMHO the qmake build files were removed prematurely ... they should be removed **after** cmake matched qmake. Probably would agree with this, but meh, whatever, I'm agile. Having said that, I truly believe that cmake is a big step backwards. Am I the only one who's bother by all these things? I would say a side step. All build systems are a pain in the posterior - buildroot, bitbake, tmake, qmake, cmake, whatever Android uses, whatever iOS uses... you name it, they all have their own issues. You don't want to know what was done to qmake to get it to build qtopia. :) We have a huge elephant in the room which nobody want to see it... I guess it's a choice of an elephant or a whale. -- Lorn Potter Freelance Qt Developer. Platform Maintainer Qt WebAssembly, Maintainer QtSensors Author, Hands-on Mobile and Embedded Development with Qt 5 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 6 co-installability with Qt 5
On 2/23/21 8:52 PM, Thiago Macieira wrote: On Tuesday, 23 February 2021 00:00:22 PST Joerg Bornemann wrote: On 2/20/21 2:44 AM, Thiago Macieira wrote: Besides, doesn't Windows now have symlinks? For admin users only unless an admin user enables them for everyone. Hard-links are available though on NTFS. Can we use the hard-links then? CMake supports creating hard links with file(CREATE_LINK). "cmake --install" does not directly support creating hard links. One would probably have to use install(SCRIPT) with a script that runs file(CREATE_LINK). For the installer, 7zip supports storing hard links since 9.33. Without trying anything, it looks like using hard links could work. Cheers, Joerg ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] The sorry state of the Qt6 cross compile experience
On 2/23/21 12:27 PM, BogDan Vatra via Development wrote: OK, biting. - first and foremost, we need to waste time to **fully** build and install it for host platform (desktop). No, you don't need a full build. You need the tools that are called by the build system. The support for creating a "minimal desktop" build could be better, sure. But you're one of few affected people. > Yeah, I know that this was "decided" before TQC > switched, overnight, to cmake, but let's face it, it's a BS needed to cover > the fact that cmake can't build more than one platform at once. Let's face it. It's a good thing to not compile the same set of tools over and over again, and it simplifies the build very much. - the cross build installation is broken, instead to copy the tools from the QT_HOST_TOOLS folder, it creates some scripts that has hardcoded paths to QT_HOST_TOOLS which runs the scripts from QT_HOST_TOOLS folder. Of course this makes the installation unusable on another computer. Even the "lib/cmake/Qt6/ qt.toolchain.cmake" contains hardcoded paths... Right. The Qt5 qmake build never had any hard-coded paths. Try again. - there is no way to have a standalone cross build installation, we always need to ship the whole desktop installation as well (also patch all the files from cross installation). Do interpret this correctly as the second attempt in your mail to kindly suggest better support for a minimal desktop build? - android cross compilation is so crippled now. In Qt 5.x times, we used to have a nice multi ABI build which built all the android ABIs in one go and it created a unified Qt SDK for all these ABIs (same as the Android NDK). In Qt 6, that work was trashed... for the same reason: cmake can't handle multiple platforms at once... That's right. We're lacking support for multi-ABI that was hacked into the Qt build where we run configure tests for one random architecture and use those configure results for all other architectures. I consider this a good thing. - android cross compilation in Qt 6 takes more time to build one ABI with less Qt modules than in Qt5 to build all ABIs and all modules... And your thorough analysis of the problem is "CMake is BS"? Don't get me wrong. Your input is always welcome, but maybe we can get away from this amusing yet somehow annoying "gramps rants about how the past was better" style. Cheers, Joerg ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 6 co-installability with Qt 5
On Tuesday, 23 February 2021 00:00:22 PST Joerg Bornemann wrote: > On 2/20/21 2:44 AM, Thiago Macieira wrote: > > Besides, doesn't Windows now have symlinks? > > For admin users only unless an admin user enables them for everyone. > Hard-links are available though on NTFS. Can we use the hard-links then? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Codereview scheduled maintenance break on Monday 1-Mar 7 am CET
Hi all, There will be a maintenance break on the codereview.qt-project.org on Monday 1-Mar 7:00 am – 8:00 am CET. The Gerrit version will be upgraded from 3.1.10 to 3.1.12. --Jukka Jokiniva ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] The sorry state of the Qt6 cross compile experience
Hi, It looks like your experience with the new build system is the very opposite of my experience. I've found it to work much more flawlessly, especially with regards to cross-compilation targeting mingw-w64 and Android (haven't tested the Android build much, though). --- > first and foremost, we need to waste time to **fully** build and install it I usually have native/non-cross build around anyways so this never occurred to me as a problem. In fact I found it quite nice that I don't have to waste time building qmake, other tools and bootstrapping libraries for all targets. Simply reusing my native/non-cross binaries seems like a win to me. > but let's face it, it's a BS needed to cover the fact that cmake can't build more than one platform at once. Again, this seems like a good thing to me. I found it always messy that qmake tries to build for multiple targets at the same time. This makes everything more complex. When adjusting some kind of flags or dependency lookup (or whatever behavior) it always raised the question: Which targets will it affect? How do I make it affect only e.g. the host build? This was not very intuitive to deal with. Keeping targets separate simplifies things. > android cross compilation is so crippled now. The multi-ABI build never worked well for me with Qt 5. While it is nice that Qt's build system offers this feature it doesn't help with the fact that other dependencies of my project don't support that. Hence it is still easier to install each architecture within its own prefix which unfortunately was broken by the multi-ABI build. Hence I don't miss that feature at all. --- I'd also like to note that with CMake the dependencies of static libraries and plugins are taken into account correctly. At least this required some heavy/ hacky patching with qmake in the past. (It might have improved in recent Qt 5 releases, though. At some point I gave up and just kept using my patches.) --- I've just wanted to share my own experience because the initial mail was overwhelmingly negative. Likely it depends very much on the use-cases, e.g. I never wanted to "ship" Qt. My main focus is packaging Qt for GNU/Linux including cross-compilation packages for mingw-w64 and Android targets. Best Regards Marius ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] The sorry state of the Qt6 cross compile experience
Hi, Even though I said that I'm not opening this subject again, I must do it because in this moment, cross compiling Qt6 is painful and broken. Long time ago, in the Qt 5 time, we had an painlessly way to do cross compiling, not only for Android, but also for the rest of the platforms. Yes, I know, Qt 5 was using the evil, outdated qmake system which we all loved to hate, but it just worked for most of us. Now cross compiling Qt6 for any platform is broken and painful: - first and foremost, we need to waste time to **fully** build and install it for host platform (desktop). Yeah, I know that this was "decided" before TQC switched, overnight, to cmake, but let's face it, it's a BS needed to cover the fact that cmake can't build more than one platform at once. - the cross build installation is broken, instead to copy the tools from the QT_HOST_TOOLS folder, it creates some scripts that has hardcoded paths to QT_HOST_TOOLS which runs the scripts from QT_HOST_TOOLS folder. Of course this makes the installation unusable on another computer. Even the "lib/cmake/Qt6/ qt.toolchain.cmake" contains hardcoded paths... - there is no way to have a standalone cross build installation, we always need to ship the whole desktop installation as well (also patch all the files from cross installation). - android cross compilation is so crippled now. In Qt 5.x times, we used to have a nice multi ABI build which built all the android ABIs in one go and it created a unified Qt SDK for all these ABIs (same as the Android NDK). In Qt 6, that work was trashed... for the same reason: cmake can't handle multiple platforms at once... - android cross compilation in Qt 6 takes more time to build one ABI with less Qt modules than in Qt5 to build all ABIs and all modules... - IMHO the qmake build files were removed prematurely ... they should be removed **after** cmake matched qmake. Having said that, I truly believe that cmake is a big step backwards. Am I the only one who's bother by all these things? We have a huge elephant in the room which nobody want to see it... Yours, BogDan. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 6 co-installability with Qt 5
On 2/20/21 2:44 AM, Thiago Macieira wrote: Besides, doesn't Windows now have symlinks? For admin users only unless an admin user enables them for everyone. Hard-links are available though on NTFS. Cheers, Joerg ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
