Re: [Development] Switch the main "Qt Build System"
Hi, The CI still uses qmake to build the examples projects, to make sure that we don't lose coverage of using qmake for application development (which is different from building Qt). That's been tested to work for all repos that are part of qt5, but i guess we missed checking the addon libraries like qtimageformats or qt3d. Please file a bug report : ) > On 11. Dec 2020, at 12:37, Mike Krus wrote: > > Some configurations still seem to use qmake for some parts: > https://testresults.qt.io/logs/qt/qt3d/5ef6de3b5deb13254200c1f385ce09008b287760/MacOSMacOS_10_14x86_64MacOSMacOS_10_14x86_64Clangqtci-macos-10.14-x86_64-f695c4DisableTests_Sccache/67c64555fe39a6412f13f7c4d92663fc0c175a7b/build_1607682919/log.txt.gz > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
Some configurations still seem to use qmake for some parts: https://testresults.qt.io/logs/qt/qt3d/5ef6de3b5deb13254200c1f385ce09008b287760/MacOSMacOS_10_14x86_64MacOSMacOS_10_14x86_64Clangqtci-macos-10.14-x86_64-f695c4DisableTests_Sccache/67c64555fe39a6412f13f7c4d92663fc0c175a7b/build_1607682919/log.txt.gz > On 11 Dec 2020, at 09:13, Alexandru Croitor wrote: > > Hi, > > qmake Qt builds have been disabled in the CI and in configure. > > Regards, > Alex. > >> On 8. Dec 2020, at 17:51, Alexandru Croitor wrote: >> >> Hi again, >> >> A short update on the build system switch. >> >> Sine my last email (half a year ago) a number of issues were raised that we >> had to tackle in order to consider switching Qt's main build system to CMake. >> >> Some of those issues were tracked in the following JIRA issues >> https://bugreports.qt.io/browse/QTBUG-86053 >> https://bugreports.qt.io/browse/QTBUG-88741 >> as well as some other ones. >> >> Since then: >> - most of the important issues have been fixed >> - multiple improvements have been done to the Qt build DeveloperXperience >> - qmake CI coverage has been mirrored >> - configure's default has been changed to build Qt with CMake >> - our CI and packaging pipelines have switched to using CMake for a while now >> - the Qt 6.0.0 that shipped today was built using CMake >> >> As such, we intend to remove support for building Qt with qmake in the 6.1 >> branch (aka dev) >> >> This means: >> - we will remove the qmake CI configurations in dev branch >> - we will change configure to refuse configuring Qt with the -qmake option >> - pro2cmake will not be used anymore, and the CMakeLists.txt files become >> the source of truth >> which means CMakeLists.txt files will now have to be modified directly >> - configurejson2cmake will not be used anymore, and the configure.cmake >> files will become the source of truth (not configure.json) >> which means configure.cmake files will now have to be modified directly >> - we will not remove the qmake .pro and configure.json files for now, it >> will be done sometime later in the future >> https://bugreports.qt.io/browse/QTBUG-88742 >> >> We intend to do it by the end of the week, if nothing critical comes up. >> >> Regards, >> Alex. >> >> >>> On 1. Jul 2020, at 13:31, Alexandru Croitor wrote: >>> >>> Hi everyone, >>> >>> An update on the build system switch. >>> >>> >>> On the 8th of June I mentioned that we wanted to make the "CMake build >>> system" the main one and remove the .pro files. >>> The tentative date was 1st of July (today). >>> >>> As a result of the discussion, we identified some items that had to be >>> tackled first. >>> Not all of those have been addressed yet. >>> >>> So we are postponing the switch until further notice. >>> >>> Regards, >>> Alexandru. >> >> ___ >> 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 — Mike Krus | mike.k...@kdab.com | Senior Software Engineer & Teamlead KDAB (UK) Ltd., a KDAB Group company Tel: UK Office +44 1625 809908 Mobile +44 7833 491941 KDAB - The Qt Experts, C++, OpenGL Experts smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
Hi, qmake Qt builds have been disabled in the CI and in configure. Regards, Alex. > On 8. Dec 2020, at 17:51, Alexandru Croitor wrote: > > Hi again, > > A short update on the build system switch. > > Sine my last email (half a year ago) a number of issues were raised that we > had to tackle in order to consider switching Qt's main build system to CMake. > > Some of those issues were tracked in the following JIRA issues > https://bugreports.qt.io/browse/QTBUG-86053 > https://bugreports.qt.io/browse/QTBUG-88741 > as well as some other ones. > > Since then: > - most of the important issues have been fixed > - multiple improvements have been done to the Qt build DeveloperXperience > - qmake CI coverage has been mirrored > - configure's default has been changed to build Qt with CMake > - our CI and packaging pipelines have switched to using CMake for a while now > - the Qt 6.0.0 that shipped today was built using CMake > > As such, we intend to remove support for building Qt with qmake in the 6.1 > branch (aka dev) > > This means: > - we will remove the qmake CI configurations in dev branch > - we will change configure to refuse configuring Qt with the -qmake option > - pro2cmake will not be used anymore, and the CMakeLists.txt files become the > source of truth > which means CMakeLists.txt files will now have to be modified directly > - configurejson2cmake will not be used anymore, and the configure.cmake files > will become the source of truth (not configure.json) > which means configure.cmake files will now have to be modified directly > - we will not remove the qmake .pro and configure.json files for now, it will > be done sometime later in the future > https://bugreports.qt.io/browse/QTBUG-88742 > > We intend to do it by the end of the week, if nothing critical comes up. > > Regards, > Alex. > > >> On 1. Jul 2020, at 13:31, Alexandru Croitor wrote: >> >> Hi everyone, >> >> An update on the build system switch. >> >> >> On the 8th of June I mentioned that we wanted to make the "CMake build >> system" the main one and remove the .pro files. >> The tentative date was 1st of July (today). >> >> As a result of the discussion, we identified some items that had to be >> tackled first. >> Not all of those have been addressed yet. >> >> So we are postponing the switch until further notice. >> >> Regards, >> Alexandru. > > ___ > 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] Switch the main "Qt Build System"
Awesome work!! Cheers, Tor Arne On 8 Dec 2020, at 17:51, Alexandru Croitor mailto:alexandru.croi...@qt.io>> wrote: Hi again, A short update on the build system switch. Sine my last email (half a year ago) a number of issues were raised that we had to tackle in order to consider switching Qt's main build system to CMake. Some of those issues were tracked in the following JIRA issues https://bugreports.qt.io/browse/QTBUG-86053 https://bugreports.qt.io/browse/QTBUG-88741 as well as some other ones. Since then: - most of the important issues have been fixed - multiple improvements have been done to the Qt build DeveloperXperience - qmake CI coverage has been mirrored - configure's default has been changed to build Qt with CMake - our CI and packaging pipelines have switched to using CMake for a while now - the Qt 6.0.0 that shipped today was built using CMake As such, we intend to remove support for building Qt with qmake in the 6.1 branch (aka dev) This means: - we will remove the qmake CI configurations in dev branch - we will change configure to refuse configuring Qt with the -qmake option - pro2cmake will not be used anymore, and the CMakeLists.txt files become the source of truth which means CMakeLists.txt files will now have to be modified directly - configurejson2cmake will not be used anymore, and the configure.cmake files will become the source of truth (not configure.json) which means configure.cmake files will now have to be modified directly - we will not remove the qmake .pro and configure.json files for now, it will be done sometime later in the future https://bugreports.qt.io/browse/QTBUG-88742 We intend to do it by the end of the week, if nothing critical comes up. Regards, Alex. On 1. Jul 2020, at 13:31, Alexandru Croitor wrote: Hi everyone, An update on the build system switch. On the 8th of June I mentioned that we wanted to make the "CMake build system" the main one and remove the .pro files. The tentative date was 1st of July (today). As a result of the discussion, we identified some items that had to be tackled first. Not all of those have been addressed yet. So we are postponing the switch until further notice. Regards, Alexandru. ___ 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] Switch the main "Qt Build System"
Hi again, A short update on the build system switch. Sine my last email (half a year ago) a number of issues were raised that we had to tackle in order to consider switching Qt's main build system to CMake. Some of those issues were tracked in the following JIRA issues https://bugreports.qt.io/browse/QTBUG-86053 https://bugreports.qt.io/browse/QTBUG-88741 as well as some other ones. Since then: - most of the important issues have been fixed - multiple improvements have been done to the Qt build DeveloperXperience - qmake CI coverage has been mirrored - configure's default has been changed to build Qt with CMake - our CI and packaging pipelines have switched to using CMake for a while now - the Qt 6.0.0 that shipped today was built using CMake As such, we intend to remove support for building Qt with qmake in the 6.1 branch (aka dev) This means: - we will remove the qmake CI configurations in dev branch - we will change configure to refuse configuring Qt with the -qmake option - pro2cmake will not be used anymore, and the CMakeLists.txt files become the source of truth which means CMakeLists.txt files will now have to be modified directly - configurejson2cmake will not be used anymore, and the configure.cmake files will become the source of truth (not configure.json) which means configure.cmake files will now have to be modified directly - we will not remove the qmake .pro and configure.json files for now, it will be done sometime later in the future https://bugreports.qt.io/browse/QTBUG-88742 We intend to do it by the end of the week, if nothing critical comes up. Regards, Alex. > On 1. Jul 2020, at 13:31, Alexandru Croitor wrote: > > Hi everyone, > > An update on the build system switch. > > > On the 8th of June I mentioned that we wanted to make the "CMake build > system" the main one and remove the .pro files. > The tentative date was 1st of July (today). > > As a result of the discussion, we identified some items that had to be > tackled first. > Not all of those have been addressed yet. > > So we are postponing the switch until further notice. > > Regards, > Alexandru. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
Hi everyone, An update on the build system switch. On the 8th of June I mentioned that we wanted to make the "CMake build system" the main one and remove the .pro files. The tentative date was 1st of July (today). As a result of the discussion, we identified some items that had to be tackled first. Not all of those have been addressed yet. So we are postponing the switch until further notice. Regards, Alexandru. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
Am 08.06.20 um 15:43 schrieb Alexandru Croitor: > Hi everyone, > > It's time to talk about everyone's favourite topic again: build systems. > > It's been a while since we started porting and merging the CMake ports of Qt > repositories into the dev branches. > > To be precise: qtbase got merged on the 7th of February. > > Since then, all the enabled repositories in qt5.git/dev have CMake ports > merged to their corresponding dev branches (except for qtqa which got > reverted, but it should be back soon). > > The CMake ports are built in Coin with the most important configurations > (Linux, Windows, macOS, Android, iOS, qemu Linux). > > Currently, failed tests don't fail integrations, but we're fixing up the last > failing tests and intend to enforce successful test passing for CMake > configurations. > > Anyway, it's time for the next step. > > > -> TL;DR here > < > > The CMake Port team wants to switch the main Qt build system to the CMake one. > > What this means: > > - All Coin qmake configurations in dev branch are removed. > > - Only CMake configurations are built in Coin. > > - CMakeLists.txt files are now the source of truth (no more editing of .pro / > .pri files). > > - All qmake .pro / .pri files of ported repositories under Coin control are > removed. Hi Alexandru, please don't remove anything from subdirectories tests/libfuzzer/ in any repository. I will take care of them myself. Cheers, Robert > - No more pro2cmake.py and configurejson2cmake.py usage (except for an > initial port of a yet un-ported repository) > > - You need CMake to build Qt. > > - Un-ported repositories should still be able to build with qmake against a > CMake built Qt (this was tested to work for qtwebengine, but not other > repositories, there are a few known issues left that we're currently fixing). > > > --> Proposed time of execution: 1st of July <-- > > > I'd like to hear about any Qt development blockers that you foresee due to > this change. > > > Regards, > Alexandru. > ___ > 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] Switch the main "Qt Build System"
Am 10.06.20 um 18:28 schrieb Thiago Macieira: > On Wednesday, 10 June 2020 04:35:51 PDT Dominik Holland wrote: >>> Strictly speaking, you don't have to build Qt twice. You can use your >>> system's packaged Qt, or Conan or Homebrew or one of the binary builds >>> from qt.io as the other. If you don't intend to develop it, you can use >>> the regular, release builds made by others. >> Mhh but that only works if your system have packaged the same Qt version >> isn't it ? I'm talking about future changes/new features of moc which >> might be needed by newer Qt versions. > See my reply to Bogdan. We should not require exact same version. We may need > to require "not newer" > > Qt needs to continue supporting older moc-generated code that was compiled > into libraries and applications and ditto for rcc, uic. So there's little > reason why the version of those tools has to be the exact same. > > Being newer could be a problem. > +1 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
On Wednesday, 10 June 2020 19:46:22 PDT Thiago Macieira wrote: > On Wednesday, 10 June 2020 13:37:02 PDT Alexandru Croitor wrote: > > > Ditto for macOS. A multi-arch x86_64 build would be welcome (x86_64 and > > > x86_64h). > > > > I think that would be a new feature request, given we don't do it > > currently > > in qmake land. > > More like a post-build action to merge the binaries into fat archives. It > doesn't need to be in CMake. Could use avxjudge.py from https://github.com/clearlinux/clr-avx-tools to determine if a file compiled for x86_64h is worth keeping & merging. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
On Wednesday, 10 June 2020 13:37:02 PDT Alexandru Croitor wrote: > > Ditto for macOS. A multi-arch x86_64 build would be welcome (x86_64 and > > x86_64h). > > I think that would be a new feature request, given we don't do it currently > in qmake land. More like a post-build action to merge the binaries into fat archives. It doesn't need to be in CMake. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
On 10. Jun 2020, at 18:13, Thiago Macieira wrote: > > On Wednesday, 10 June 2020 00:44:48 PDT Alexandru Croitor wrote: >> It is. Building Qt targeting Android with CMake works, but you only get one >> architecture (arm64 for example) in a single build tree, instead of more >> than one (arm64, armv7, x86, x64) like you used to when building with >> qmake. We will revisit the multi-arch approach later. > > Can they be merged after building? If so, that might be the long-term > solution. I thought there's nothing special about the android multi arch build in the sense that in the end it's just a bunch of differently named files being in the same install prefix (as opposed to iOS where there are fat archives), but i can't be sure because i didn't look into it. So I don't really know atm if they can be merged or not. > > Ditto for macOS. A multi-arch x86_64 build would be welcome (x86_64 and > x86_64h). I think that would be a new feature request, given we don't do it currently in qmake land. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
On Wednesday, 10 June 2020 04:35:51 PDT Dominik Holland wrote: > > Strictly speaking, you don't have to build Qt twice. You can use your > > system's packaged Qt, or Conan or Homebrew or one of the binary builds > > from qt.io as the other. If you don't intend to develop it, you can use > > the regular, release builds made by others. > > Mhh but that only works if your system have packaged the same Qt version > isn't it ? I'm talking about future changes/new features of moc which > might be needed by newer Qt versions. See my reply to Bogdan. We should not require exact same version. We may need to require "not newer" Qt needs to continue supporting older moc-generated code that was compiled into libraries and applications and ditto for rcc, uic. So there's little reason why the version of those tools has to be the exact same. Being newer could be a problem. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
On Tuesday, 9 June 2020 23:07:55 PDT Bogdan Vatra via Development wrote: > > The whole point of not bootstrapping the tools for cross compilation is to > > remove as much as we can of the bootstrapping. Right now in 5.15, the only > > tools that really need bootstrapping are qmake and moc. And for 6.0 once > > the build system switch is merged, we can proceed to un-bootstrap qmake > > too and that removes one full level of bootstrapping. > > > > That will leave us with only moc needing bootstrapping. We can therefore > > remove libQt5Bootstrap.a and minimise the amount of work needed to keep > > the > > bootstrap working. > > In this case why did you all had the super strict requirement list when we > talked about using qbs as the build system for Qt 6? And why now you are so > understanding and flexible with all the missing pieces from cmake? I don't think I am being less strict. The strict requirement is that Qt does not require Qt for a non-cross-compilation. There has to be a starting point in the build chain. For a non-cross-compilation, there's a single build necessary; for a cross compilation, two and one of them could be minimal. Clang can be compiled with GCC GCC used to be compilable with other, Unix C compilers GNU tar is packaged as a .shar file too zlib used to be available as uncompressed .tar; now it has a .tar.xz > There are host tools that are not very forward or backward compatible > (e.g. androiddeployqt) which might require a specific Qt version as it > knows how to deal with a specific input files... Those tools rely very much on internals *because* they've always been tied to a particular version, so people took liberties in writing those tools. Most should be updated so that they don't. We don't have to fix this for 6.0. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
On Wednesday, 10 June 2020 00:44:48 PDT Alexandru Croitor wrote: > It is. Building Qt targeting Android with CMake works, but you only get one > architecture (arm64 for example) in a single build tree, instead of more > than one (arm64, armv7, x86, x64) like you used to when building with > qmake. We will revisit the multi-arch approach later. Can they be merged after building? If so, that might be the long-term solution. Ditto for macOS. A multi-arch x86_64 build would be welcome (x86_64 and x86_64h). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
On 09/06/2020 14.38, Thiago Macieira wrote: On Tuesday, 9 June 2020 00:27:35 PDT Shawn Rutledge wrote: FWIW the configuration mechanism seems a bit less friendly so far with all those -DSHOUTED options like -DFEATURE_developer_build=ON instead of configure -developer-build. The syntax of CMake was why KDE decided in 2004 not to use CMake and instead use Scons/Waf. Worked out pretty well, right? The maturity of the project matters A LOT more than the syntax. Yup. This is a cold, hard truth, but it *is* the truth. If it wasn't, CMake would either a) not be as successful as it is, or b) wouldn't have this issue. Yes, the syntax/language is a wart. Everyone knows that and would like to do something about it, *including the CMake developers*. So far, however, no one has stepped up to do that work. Several build systems (including QBS) have tried to supplant CMake, but have not yet succeeded. Build systems are *hard*, and the complexity that folks like to point to as one of CMake's biggest "flaws" exists for a reason. Nor is switching to a new scripting language as straight-forward as you might think. Again, someone that cares enough to dig in to the necessary degree (or pony up the cash to pay for doing so) would be *welcomed*. -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
Am 6/9/20 um 8:34 PM schrieb Thiago Macieira: > On Tuesday, 9 June 2020 05:52:30 PDT Alexandru Croitor wrote: >>> I'm using qmake for Qt6 when I'm doing Android work, also for this reason. >>> I don't want to build Qt twice just to use a "cool and superior" build >>> system. >> Unfortunately that workflow will not work anymore. > Strictly speaking, you don't have to build Qt twice. You can use your > system's > packaged Qt, or Conan or Homebrew or one of the binary builds from qt.io as > the other. If you don't intend to develop it, you can use the regular, > release > builds made by others. > Mhh but that only works if your system have packaged the same Qt version isn't it ? I'm talking about future changes/new features of moc which might be needed by newer Qt versions. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
On 10. Jun 2020, at 04:39, André Pönitz wrote: >> [...] at least in the early phases of a bisection one has to find out >> what setup has to used to build a module, too. Alexandru Croitor (10 June 2020 09:44) replied: > Yes. But how could we improve this really? Do we create some file in > the root tree called "repo_does_not_build_with_qmake_anymore.txt"? No need for an extra file: just check for src/src.pro - if it's not there, the module's in cmake-only state - and src/CMakeLists.txt - if that's not there, the module's in qmake-only mode. If both are present, use either or both. The first step of that is, of course, one more argument in favour of killing *.pr[fio] as soon as we stop using them in CI (since bisect is apt to fail after that, if it tries to use qmake, due to the qmake config having bit-rotted). Bisecting across the divide shall be "harder than usual" but such a heuristic makes it *possible* for a script to do the build-and-test. As time goes by, the need for such bisects shall become rarer. Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
> On 10. Jun 2020, at 04:39, André Pönitz wrote: > >> Here you can see the configurations that are rested currently in Coin. >> >> https://code.qt.io/cgit/qt/qt5.git/tree/coin/platform_configs/qtsvg.yaml >> (svg is >> just an example) >> >> So desktop Ubuntu, static qt builds on Suse, macOS framework builds (non-fw >> also >> work), Windows MSVC2019, Windows MinGW 8, Android Arm64, iOS arm64. > > I don't see any build there that looks like it might be a namespaced build. > This has a high chance to not meet the "compiles" condition above for me. That's right, there's no namespace build tested in the CI at the moment. I'll create a bug report so we try and add one. > >> I'm waiting on some updates to switch iOS to simulator_and_device. >> >> Android multi-ABI is currently not implemented, and we don't plan to do it >> for >> 6.0. > > Isn't Android support part of qtbase? It is. Building Qt targeting Android with CMake works, but you only get one architecture (arm64 for example) in a single build tree, instead of more than one (arm64, armv7, x86, x64) like you used to when building with qmake. We will revisit the multi-arch approach later. > >> We don't have WebAssembly at the moment, but it was tested to work at some >> point. >> >> Not shown here, we also have a Linux embedded arm qemu configuration in Coin >> for >> qtbase, which will be expanded to other modules. >> >>> Will it be possible to use bisect "all of Qt" with reasonable effort also >>> for >>> changes in the time until the transition is complete and the result is >>> stable? >>> E.g. will there be clear which state of which module compiles with which >>> state >>> of other modules with no or only short non-compilable phases inbetween? >> >> If i understand correctly, this touches upon 2 topics. >> >> 1) if we remove .pro files, there will be 3 periods of build systems. Before >> 6.0, you'll have to configure and build with qmake, then a short period where >> you can build with qmake and somewhat with cmake (depends on how far in the >> past >> you go and at what state the cmake port was in that time), and post-removal >> of >> .pro files, you'll only be able to build with cmake. >> >> I don't think i can give you exact commit sets for that, so yes, it'll >> probably >> be painful. > > Given the amount of Qt5->6 code changes that would be an unfortunate > situation. > > Do you think it is really necessary to remove the .pro files at once? Wouldn't > just not using them for your CMake file generation already be enough for you > to proceed? The desire is to get rid of the .pro files so we don't have to depend on the not-perfect-tool and not-perfect-situation that we have now. The proposal was fast-tracked due to issues that people already have when they need to touch .pro files I mentioned them in one of my replies to Alex (people don't use the tool, refuse to use the tool, don't want to touch the cmakelists.txt files, this leads to further integration issues for other people, etc). > >> 2) dependencies.yaml >> >> Which module compiles against which other module seems like a separate >> concern >> that is not entirely related to the build system in all cases. >> >> Figuring out combos of which module sha1s can be built together is already >> somewhat of an issue with the current qmake build system, so that part is >> out of >> scope for the CMake port team. > > It was not about module sha1, but figuring out the way modules are build given > a sha1. Effectively this would mean that at least in the early phases of a > bisection one has to find out what setup has to used to build a module, too. Yes. But how could we improve this really? Do we create some file in the root tree called "repo_does_not_build_with_qmake_anymore.txt"? > >> Are you suggesting we somehow annotate the CMake part of the question? Like >> "we >> guarantee you can build qtbase, qtdeclarative, qtquickcontrols2 with CMake >> with >> SHAs X Y and Z? I'm not sure how useful that will be, given dev is constantly >> moving forward. > > I think part of the issue would be avoided if the .pro file were not purged > until CMake is a full replacement. "Full replacement" is a strong requirement which differs from person to person. Of course it would be great if *everything* is done, and we flip a switch and everything works amazingly. The reality is different though, and we need to switch at some point sooner rather than later. The question becomes when, and what are the blockers for that, other than some inconvenience and an adaptation period. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
On 6/10/20 4:39 AM, André Pönitz wrote: Android multi-ABI is currently not implemented, and we don't plan to do it for 6.0. Isn't Android support part of qtbase? It is. Android multi-ABI is "building Qt for Android for multiple ABIs in one go" instead of "building Qt per ABI". The former was added to Qt 5.14.0 and is not crucial to provide Android support. Do you think it is really necessary to remove the .pro files at once? Wouldn't just not using them for your CMake file generation already be enough for you to proceed? The idea is to have one source of truth instead of two. Right now we (CMake guys) consider the pro files to be the source. But people tend to make manual adjustments to the CMake files which creates extra work for re-generating them. Another advantage of removing the pro files is: reduced CI build times. When would be a convenient time for you to remove the qmake project files? We certainly don't want to keep them around forever. Are you suggesting we somehow annotate the CMake part of the question? Like "we guarantee you can build qtbase, qtdeclarative, qtquickcontrols2 with CMake with SHAs X Y and Z? I'm not sure how useful that will be, given dev is constantly moving forward. I think part of the issue would be avoided if the .pro file were not purged until CMake is a full replacement. What's missing? Cheers, Joerg ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
> On 10. Jun 2020, at 03:35, Lorn Potter wrote: > > > > On 9/6/20 11:23 PM, Alexandru Croitor wrote: >>> - WebAssembly completely lost >> That is true. As I mentioned in my reply to Andre, we tested it at some >> point, but we don't have current plans to add it to the CI. > > I would be surprised if it actually built, as emscripten compiler for Qt > WebAssembly needs special linker flags (beyond what is in the toolchain > file), as well as in the platform app build, we move files and sed replace > strings to make it all work. > > I spent an hour or so today trying to get dev branch built for webassembly > using cmake, and could not get past the initial cmake call. > Note that my "tested at some point" did not mean it works now. Merely that a conclusion was made that it should be doable. Personally I never dove into gritty details of making it work, and when I tried to set it up once, I failed as well. But I know that when somebody did look into it, they were able to build qtbase (this is when we were still using vcpkg for some of the 3rd party dependencies). ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
On Tue, Jun 09, 2020 at 08:06:57AM +, Alexandru Croitor wrote: > > On 9. Jun 2020, at 04:32, André Pönitz wrote: > > > > On Mon, Jun 08, 2020 at 01:43:20PM +, Alexandru Croitor wrote: > >> [...] > >> The CMake ports are built in Coin with the most important configurations > >> (Linux, Windows, macOS, Android, iOS, qemu Linux). > > > > Is there a list of configurations that work/do not work? > > I'm not sure what your definition of works is. My definition of "works" in this context is "Doesn't get in my way, i.e. compiles, and doesn't crash for the things I am using". > Here you can see the configurations that are rested currently in Coin. > > https://code.qt.io/cgit/qt/qt5.git/tree/coin/platform_configs/qtsvg.yaml (svg > is > just an example) > > So desktop Ubuntu, static qt builds on Suse, macOS framework builds (non-fw > also > work), Windows MSVC2019, Windows MinGW 8, Android Arm64, iOS arm64. I don't see any build there that looks like it might be a namespaced build. This has a high chance to not meet the "compiles" condition above for me. > I'm waiting on some updates to switch iOS to simulator_and_device. > > Android multi-ABI is currently not implemented, and we don't plan to do it for > 6.0. Isn't Android support part of qtbase? > We don't have WebAssembly at the moment, but it was tested to work at some > point. > > Not shown here, we also have a Linux embedded arm qemu configuration in Coin > for > qtbase, which will be expanded to other modules. > > > Will it be possible to use bisect "all of Qt" with reasonable effort also > > for > > changes in the time until the transition is complete and the result is > > stable? > > E.g. will there be clear which state of which module compiles with which > > state > > of other modules with no or only short non-compilable phases inbetween? > > If i understand correctly, this touches upon 2 topics. > > 1) if we remove .pro files, there will be 3 periods of build systems. Before > 6.0, you'll have to configure and build with qmake, then a short period where > you can build with qmake and somewhat with cmake (depends on how far in the > past > you go and at what state the cmake port was in that time), and post-removal of > .pro files, you'll only be able to build with cmake. > > I don't think i can give you exact commit sets for that, so yes, it'll > probably > be painful. Given the amount of Qt5->6 code changes that would be an unfortunate situation. Do you think it is really necessary to remove the .pro files at once? Wouldn't just not using them for your CMake file generation already be enough for you to proceed? > 2) dependencies.yaml > > Which module compiles against which other module seems like a separate concern > that is not entirely related to the build system in all cases. > > Figuring out combos of which module sha1s can be built together is already > somewhat of an issue with the current qmake build system, so that part is out > of > scope for the CMake port team. It was not about module sha1, but figuring out the way modules are build given a sha1. Effectively this would mean that at least in the early phases of a bisection one has to find out what setup has to used to build a module, too. > Are you suggesting we somehow annotate the CMake part of the question? Like > "we > guarantee you can build qtbase, qtdeclarative, qtquickcontrols2 with CMake > with > SHAs X Y and Z? I'm not sure how useful that will be, given dev is constantly > moving forward. I think part of the issue would be avoided if the .pro file were not purged until CMake is a full replacement. Andre' ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
În ziua de marți, 9 iunie 2020, la 21:31:17 EEST, Thiago Macieira a scris: > On Tuesday, 9 June 2020 01:26:12 PDT Alexandru Croitor wrote: > > > On 9. Jun 2020, at 10:17, Jean-Michaël Celerier > > > wrote: > > > > > > To simplify this step, is there / could there be maybe a > > > -DQT_BUILD_TOOLS_ONLY that would just generate... well, moc, uic, rcc > > > and > > > a couple other friends required for a cross-build ? > > > > I think that should technically be possible, but I have doubts about it. > > > > Not all tools are "bootstrap" tools anymore, which means for uic you need > > to build QtCore (same for qmake actually). > > The whole point of not bootstrapping the tools for cross compilation is to > remove as much as we can of the bootstrapping. Right now in 5.15, the only > tools that really need bootstrapping are qmake and moc. And for 6.0 once the > build system switch is merged, we can proceed to un-bootstrap qmake too and > that removes one full level of bootstrapping. > > That will leave us with only moc needing bootstrapping. We can therefore > remove libQt5Bootstrap.a and minimise the amount of work needed to keep the > bootstrap working. In this case why did you all had the super strict requirement list when we talked about using qbs as the build system for Qt 6? And why now you are so understanding and flexible with all the missing pieces from cmake? There are host tools that are not very forward or backward compatible (e.g. androiddeployqt) which might require a specific Qt version as it knows how to deal with a specific input files... Cheers, BogDan. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
On 9/6/20 11:23 PM, Alexandru Croitor wrote: - WebAssembly completely lost That is true. As I mentioned in my reply to Andre, we tested it at some point, but we don't have current plans to add it to the CI. I would be surprised if it actually built, as emscripten compiler for Qt WebAssembly needs special linker flags (beyond what is in the toolchain file), as well as in the platform app build, we move files and sed replace strings to make it all work. I spent an hour or so today trying to get dev branch built for webassembly using cmake, and could not get past the initial cmake call. -- Lorn Potter Freelance Qt Developer. Maintainer QtSensors, Qt WebAssembly ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
On Tuesday, 9 June 2020 01:26:12 PDT Alexandru Croitor wrote: > > On 9. Jun 2020, at 10:17, Jean-Michaël Celerier > > wrote: > > > > To simplify this step, is there / could there be maybe a > > -DQT_BUILD_TOOLS_ONLY that would just generate... well, moc, uic, rcc and > > a couple other friends required for a cross-build ? > I think that should technically be possible, but I have doubts about it. > > Not all tools are "bootstrap" tools anymore, which means for uic you need to > build QtCore (same for qmake actually). The whole point of not bootstrapping the tools for cross compilation is to remove as much as we can of the bootstrapping. Right now in 5.15, the only tools that really need bootstrapping are qmake and moc. And for 6.0 once the build system switch is merged, we can proceed to un-bootstrap qmake too and that removes one full level of bootstrapping. That will leave us with only moc needing bootstrapping. We can therefore remove libQt5Bootstrap.a and minimise the amount of work needed to keep the bootstrap working. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
On Tuesday, 9 June 2020 05:52:30 PDT Alexandru Croitor wrote: > > I'm using qmake for Qt6 when I'm doing Android work, also for this reason. > > I don't want to build Qt twice just to use a "cool and superior" build > > system. > Unfortunately that workflow will not work anymore. Strictly speaking, you don't have to build Qt twice. You can use your system's packaged Qt, or Conan or Homebrew or one of the binary builds from qt.io as the other. If you don't intend to develop it, you can use the regular, release builds made by others. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
On Tuesday, 9 June 2020 00:27:35 PDT Shawn Rutledge wrote: > FWIW the configuration mechanism seems a bit less friendly so far with all > those -DSHOUTED options like -DFEATURE_developer_build=ON instead of > configure -developer-build. The syntax of CMake was why KDE decided in 2004 not to use CMake and instead use Scons/Waf. Worked out pretty well, right? The maturity of the project matters A LOT more than the syntax. Adding a wrapper configure script is easy but was never done. PS: between the initial assessment and when KDE begun using CMake, CMake stopped requiring all-uppercase and stopped requiring repeating the conditions in the ENDIF() control words. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
Den tis 9 juni 2020 kl 16:30 skrev Matthew Woehlke : > > On 09/06/2020 03.55, Joerg Bornemann wrote: > > The description of QT_NO_MAKE_TESTS is: "Should tests be built as part > > of the default 'all' target." Meaning this variable controls whether > > tests are build by default. > > Might I suggest a less obtuse name? Something along the lines of > QT_TESTS_EXCLUDE_FROM_ALL would be more typical. +1 > > -- > Matthew > ___ > 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] Switch the main "Qt Build System"
On 09/06/2020 05.05, Alexandru Croitor wrote: On 09/06/2020 04.38, Shawn Rutledge wrote: >> At least json is easier to parse, if we try to write other tooling.> > That's true. But using tooling to forever generate cmake files from json also comes with its downsides (maintenance, inability to express certain constructs, people forgetting to use it, etc). Personally I think having one source of truth is better. And I think tooling for parsing cmake files will appear in time as well. Alternatively: teach CMake to parse the .json directly. I think it would make sense for CMake to have some abilities to consume and manipulate JSON from CMake script¹, maybe even to use JSON as a replacement for the current CMakeCache.txt. (I would *definitely* like to see a JSON replacement for how CMake exports targets.) I think you might find upstream surprisingly amenable *if* someone is willing to do the work. (¹ ...or from something that *replaces* CMake script. Folks have been talking about that for ages, but it comes down to a) agreeing what to use, and b) SHTDI. If someone had a *viable* proposal for replacing² CMake script, I think you'd find the developers ***very*** interested.) (² Technically, I should say "supplementing", since CMake script needs to stick around for backwards compatibility.) -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
On 9. Jun 2020, at 16:30, Matthew Woehlke wrote: > > On 09/06/2020 03.55, Joerg Bornemann wrote: >> The description of QT_NO_MAKE_TESTS is: "Should tests be built as part of >> the default 'all' target." Meaning this variable controls whether tests are >> build by default. > > Might I suggest a less obtuse name? Something along the lines of > QT_TESTS_EXCLUDE_FROM_ALL would be more typical. If you could please file a bug report, or we might forget about it. Or even more appreciated - provide a patch. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
On 09/06/2020 03.27, Shawn Rutledge wrote: FWIW the configuration mechanism seems a bit less friendly so far with all those -DSHOUTED options like -DFEATURE_developer_build=ON instead of configure -developer-build. But there is cmake-gui, which generates checkboxes for all the options after you have run cmake the first time. There's also ccmake, which I usually use on not-Windows. It doesn't *filter* the way cmake-gui does, but it does still have searching. I rarely specify -Dstuff "by hand". If you have done a build without tests or examples at first (for speed), and then you want to build some specific ones, how do you do that? Enable testing, build specific targets. I see the same nice configure summary is still generated, but it would be nice to keep writing that to a file like the old configure system does, for later inspection. I haven't looked, but it seems like that should be feasible. Certainly you can write files at configure time, so it should be possible to have whatever prints this summary wrapped in a helper that both prints to the console and also to a file. Will we keep using the configure.json files and generating configure.cmake from them? Then maybe we could write a better gui later on, that can show checkboxes before you run cmake the first time. The problem with this is that options spring into existence *from running CMake*. When you have options that depend on other options, you can get into a sort of catch-22. This can be somewhat mitigated by arranging the CMake logic so that options are declared as soon as possible. (It might be useful if there was a non-fatal way to abort running CMake when a front-end is in use. You'd still have to "configure" once, but that initial configure could be much, much faster if all it does is declare options and bail. OTOH, while stuff like compiler detection might still need to happen in that first pass, that gets cached; you aren't actually doing it twice.) That's not to say there might not be room for improvement, but lets please make any such improvements to CMake itself so that all projects using CMake can benefit, not just Qt. -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
> On 9. Jun 2020, at 16:09, Alex Blasche wrote: > > > Again this question was referring to the "build Qt module" with CMake Qt (aka > your Webengine experiment). Not updating the dependencies is not desired at > all. Sorry, I missed that the question was about qmake mixing. You compile qtbase, qtdeclarative, etc with cmake as usual (qtbase/cmake/README.md), and then you call qt_prefix_install_path/bin/qmake on qtwebengine.pro && make && make install. I've mentioned though, there are a few known issues tracked at https://bugreports.qt.io/browse/QTBUG-84781 > > >>> About 30 out of 50 modules where set to ignore in gitmodules. About half of >> those 30 modules get very regular updates at the very least to push their >> dependencies.yaml forward. Often those cases involve porting to new qtbase >> changes. >> >> Just as a clarification, the ignored modules in .gitmodules are ignored >> initially >> not due to CMake, but to ease qt5.git integrations because of the fast >> turnover >> in qtbase and qtdeclarative. It would be unfair to pin that on the CMake >> port. > > I am not blaming CMake port for the ignored status. I am pointing out a > failure of your proposal only doing the non-ignored modules. A lot of ignored > modules have a high update frequency which you leave in the lurch with your > proposal. Right now this feels to me like releasing Joerg from his qmake duty > and bully 60% of all modules into the corner. What you have enabled for CMake > in CI will not deteriorate further. You had a trajectory going to convert the > non-ignored modules converted. Why stop here and not continue? By 1.8. > enabling cmake in CI could be done for 90% of the high turn over modules by > the cmake experts, the module experts could continue on the task of updating > against the myriads of other API changes. I bet with you that benefit > outweighs the qmake maintenance effort. The trajectory was always to port and enable in the CI, the modules that are not ignored in qt5.git. There was no plan to port all modules in the qt/ namespace by the CMake Port team. Is asking module owners to port to CMake really bullying? The fact that CMake configs do not deteriorate in the CI is not true. While .pro files and qmake are the source of truth, people change the .pro / .pri / .prf file. They either forget or don't modify the cmake equivalents. Best-case the integration fails and they also do the cmake bits. Worst case the change integrates, and somewhere along the way another integration fails due to some combination of reasons that includes the fact that the previous change did not have the cmake bits. The usual workflow is then to ask me or Joerg for help because that blocks all further integrations. > > Using arguments like the python scripts pro2cmake.py is not effort. It > doesn't count as argument Not sure i understand this point. >> >> I guess my best answer is: over time, yes. >> >> I'm slowly doing that for iOS and qemu, but it's a very slow process because >> i >> need to wait for qtbase integrations (where my fixes usually are) to >> propagate >> to other repos, or all the way to qt5. >> >>> This creates a big long term problem. For example: >>> >>> - there is only on mac build one cmake -> 3 qmake (drops >>> debug-and-release, drops building examples, no developer build) >> >> We didn't want to blow up Coin integration times, so we didn't include so far >> every possible configuration. >> Building examples and developer build activation is a simple change. For >> debug- >> and-release we are waiting for the CMake 3.18 official release. > > Take one qmake config off and add an equivalent cmake conf. You swap one for > one. There is no blow up. This is something you can do even today and you > don't need to change any policy. If we gradually replace qmake configs with cmake configs, then we lose qmake coverage, which means that people using qmake to build the modules will more likely start getting failures (especially in leaf modules), and this will again split the effort of fixing issues in 2 build systems. > >>> - Linux QEMU (completely dropped from auto testing) >> >> That's on the to do list to enable. >> >>> - WebAssembly completely lost >> >> That is true. As I mentioned in my reply to Andre, we tested it at some >> point, but >> we don't have current plans to add it to the CI. >> >>> - not a single namespace or libinfix build left (afaict) >> >> That's also true, and would have to be investigated. >> >>> - various other configurations are missing too >>> >>> Unless we can at least convert a couple more CI configurations to cmake it >> sounds to me we want to save effort on the build system side against a big >> black >> box of unknown/not tested problems we won't even notice. >> >> That is also true. But I'll ask one more time. How long do we wait? When >> everything is perfectly ready? What if that takes too long and doesn't fit >> in
Re: [Development] Switch the main "Qt Build System"
On 09/06/2020 03.55, Joerg Bornemann wrote: The description of QT_NO_MAKE_TESTS is: "Should tests be built as part of the default 'all' target." Meaning this variable controls whether tests are build by default. Might I suggest a less obtuse name? Something along the lines of QT_TESTS_EXCLUDE_FROM_ALL would be more typical. -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
> -Original Message- > From: Alexandru Croitor > > Could you share details how this is done? > > Which part? > First we'd have to remove all qmake configs in qt5.git/coin/platform_configs, > leaving just the cmake ones. > Once that's integrated, we can push & stage changes that remove .pro files. This was referring directly to the line above it. How do I build a qmake module using CMake Qt? You mentioned the possibility and having done so with webengine but never provided details. > > Can I assume that existing CI targets for those not activated cmake modules > continue to work (despite continuing dependencies.yaml updates)? > > If a module does not have a cmake port, the safe option is to use dependency > sha1s that still have the .pro files, which means you can't update > dependencies.yaml past that point. Again this question was referring to the "build Qt module" with CMake Qt (aka your Webengine experiment). Not updating the dependencies is not desired at all. > > About 30 out of 50 modules where set to ignore in gitmodules. About half of > those 30 modules get very regular updates at the very least to push their > dependencies.yaml forward. Often those cases involve porting to new qtbase > changes. > > Just as a clarification, the ignored modules in .gitmodules are ignored > initially > not due to CMake, but to ease qt5.git integrations because of the fast > turnover > in qtbase and qtdeclarative. It would be unfair to pin that on the CMake port. I am not blaming CMake port for the ignored status. I am pointing out a failure of your proposal only doing the non-ignored modules. A lot of ignored modules have a high update frequency which you leave in the lurch with your proposal. Right now this feels to me like releasing Joerg from his qmake duty and bully 60% of all modules into the corner. What you have enabled for CMake in CI will not deteriorate further. You had a trajectory going to convert the non-ignored modules converted. Why stop here and not continue? By 1.8. enabling cmake in CI could be done for 90% of the high turn over modules by the cmake experts, the module experts could continue on the task of updating against the myriads of other API changes. I bet with you that benefit outweighs the qmake maintenance effort. Using arguments like the python scripts pro2cmake.py is not effort. It doesn't count as argument > Also note that merging the wip/cmake branches to dev is fine from my point of > view. The problem is enabling it in the blocking CI, because if the port > doesn't > work, you're blocking any further integrations. There's also the minor issue > that > people might see the cmakelists.txt and think that means the port is done, but > that's minor in the grand scheme of things. > > See my previous replies regarding qmake mixing (qmake against CMake Qt). Please provide the details. How does one set such a build up? > >> --> Proposed time of execution: 1st of July <-- > >> > >> > >> I'd like to hear about any Qt development blockers that you foresee > >> due to this change. > > > > Will you create test/configuration parity in the CI? Currently the CMake > configurations don't even cover all the config options we support via qmake. > > I guess my best answer is: over time, yes. > > I'm slowly doing that for iOS and qemu, but it's a very slow process because i > need to wait for qtbase integrations (where my fixes usually are) to propagate > to other repos, or all the way to qt5. > > > This creates a big long term problem. For example: > > > > - there is only on mac build one cmake -> 3 qmake (drops > > debug-and-release, drops building examples, no developer build) > > We didn't want to blow up Coin integration times, so we didn't include so far > every possible configuration. > Building examples and developer build activation is a simple change. For > debug- > and-release we are waiting for the CMake 3.18 official release. Take one qmake config off and add an equivalent cmake conf. You swap one for one. There is no blow up. This is something you can do even today and you don't need to change any policy. > > - Linux QEMU (completely dropped from auto testing) > > That's on the to do list to enable. > > > - WebAssembly completely lost > > That is true. As I mentioned in my reply to Andre, we tested it at some > point, but > we don't have current plans to add it to the CI. > > > - not a single namespace or libinfix build left (afaict) > > That's also true, and would have to be investigated. > > > - various other configurations are missing too > > > > Unless we can at least convert a couple more CI configurations to cmake it > sounds to me we want to save effort on the build system side against a big > black > box of unknown/not tested problems we won't even notice. > > That is also true. But I'll ask one more time. How long do we wait? When > everything is perfectly ready? What if that takes too long and doesn't fit in > the >
Re: [Development] Switch the main "Qt Build System"
> On 9. Jun 2020, at 13:56, Alex Blasche wrote: > > > Could you share details how this is done? Which part? First we'd have to remove all qmake configs in qt5.git/coin/platform_configs, leaving just the cmake ones. Once that's integrated, we can push & stage changes that remove .pro files. > Can I assume that existing CI targets for those not activated cmake modules > continue to work (despite continuing dependencies.yaml updates)? If a module does not have a cmake port, the safe option is to use dependency sha1s that still have the .pro files, which means you can't update dependencies.yaml past that point. You can try updating dependencies.yaml past the removal point and thus try using the qmake mixing, but as I've mentioned in a previous reply I can't guarantee that it will work for all modules in all configurations. The best way is to port the module to CMake. > > About 30 out of 50 modules where set to ignore in gitmodules. About half of > those 30 modules get very regular updates at the very least to push their > dependencies.yaml forward. Often those cases involve porting to new qtbase > changes. Just as a clarification, the ignored modules in .gitmodules are ignored initially not due to CMake, but to ease qt5.git integrations because of the fast turnover in qtbase and qtdeclarative. It would be unfair to pin that on the CMake port. > A lot of those modules have a cmake port in a side branch. When asked about > this a few weeks ago why we shouldn't merge them to dev you stated that you > don't have the bandwidth to help people activating them in the CI. Do you > suddenly have the bandwidth to help all those module maintainers to port them > to cmake or even enable the qmake against CMake Qt? I never have enough bandwidth. That being said, I still try to help the maintainers with the ports and activating them in the CI (see for example qtopcua, qt3d and qtmqtt). I believe I also provided feedback for one of the modules that you were trying to enable in the CI. Also note that merging the wip/cmake branches to dev is fine from my point of view. The problem is enabling it in the blocking CI, because if the port doesn't work, you're blocking any further integrations. There's also the minor issue that people might see the cmakelists.txt and think that means the port is done, but that's minor in the grand scheme of things. See my previous replies regarding qmake mixing (qmake against CMake Qt). > > >> --> Proposed time of execution: 1st of July <-- >> >> >> I'd like to hear about any Qt development blockers that you foresee due to >> this >> change. > > Will you create test/configuration parity in the CI? Currently the CMake > configurations don't even cover all the config options we support via qmake. I guess my best answer is: over time, yes. I'm slowly doing that for iOS and qemu, but it's a very slow process because i need to wait for qtbase integrations (where my fixes usually are) to propagate to other repos, or all the way to qt5. > This creates a big long term problem. For example: > > - there is only on mac build one cmake -> 3 qmake (drops debug-and-release, > drops building examples, no developer build) We didn't want to blow up Coin integration times, so we didn't include so far every possible configuration. Building examples and developer build activation is a simple change. For debug-and-release we are waiting for the CMake 3.18 official release. > - Linux QEMU (completely dropped from auto testing) That's on the to do list to enable. > - WebAssembly completely lost That is true. As I mentioned in my reply to Andre, we tested it at some point, but we don't have current plans to add it to the CI. > - not a single namespace or libinfix build left (afaict) That's also true, and would have to be investigated. > - various other configurations are missing too > > Unless we can at least convert a couple more CI configurations to cmake it > sounds to me we want to save effort on the build system side against a big > black box of unknown/not tested problems we won't even notice. That is also true. But I'll ask one more time. How long do we wait? When everything is perfectly ready? What if that takes too long and doesn't fit in the 6.0 release schedule or feature freeze or platform freeze, or any other randomly chosen milestone period? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
> On 9. Jun 2020, at 13:25, Bogdan Vatra via Development > wrote: > > But how can I send a fix to a .pr* file in dev if that file doesn't exists > anymore in dev? In this case should we send the patches directly to 5.15. and > add the "Cherry-pick: dev" thing to the patch message? I think the idea is that your change initially targets the dev branch, and has a Pick-to: 5.15 footer. Let's say you will touch src/corelib/CMakeLists.txt and qlocale.cpp. When the cherry-pick bot creates the cherry-pick, it fails to apply the CMakeLists.txt file change. You then amend that change to remove the CMakeLists.txt change, and replace it with the .pro change. You could perhaps prepare the .pro file change beforehand locally, and just amend the Change-Id once the cherry-pick bots creates it. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
> On 9. Jun 2020, at 13:20, Shawn Rutledge wrote: > > >> On 2020 Jun 9, at 11:05, Alexandru Croitor wrote: >> >>> On 9. Jun 2020, at 10:38, Shawn Rutledge wrote: >>> >>> Well that’s a little extra maintenance work then; I agree that configure is >>> nicer, but maybe we can expect the cmake way of configuring to generally be >>> more up-to-date if that’s where each change starts. >> >> Up-to-date how? > > A new flag is defined to exist when it's available to cmake. But if you say > that configure needs work to stay in sync, then maybe that’s delayed? Sorry but I don't understand what you mean. > >> Are you suggesting modifying upstream cmake to accept things like >> --developer-build and map that to -DDEVELOPER_BUILD=ON or something along >> those lines? > > Do you mean cmake could generally try convert unidentified --xxx to -DXXX=ON, > or just a few flags that Qt and other projects might agree to use? I guess > either way it depends whether such upstream features would be useful to other > projects. I was thinking more of the former approach (--xxx to -DXXX=ON), but yes, it would need convincing upstream, and i'm not sure how willing they might be to do such a change. > >> I think we'll have to investigate if there's any better way to address >> discoverability. One random idea would be to provide a --list-features >> option to configure which behind the scenes calls a separate cmake script >> that finds and includes all configure.cmake files, collates a list of >> features and prints them on the command line. > > For cmake to be able to read config files and generate a list of possible > flags without doing a lot of other work sounds like a useful upstream feature. I suppose. But that's just one more "useful" feature in the pile of "nice-to-have-features" for CMake. Unfortunately there's always a lack of people to implement them. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
> On 9. Jun 2020, at 12:07, Bogdan Vatra wrote: > > Hi, > În ziua de marți, 9 iunie 2020, la 11:13:21 EEST, Alexandru Croitor a scris: >>> On 9. Jun 2020, at 07:22, Bogdan Vatra wrote: >>> >>> - is it possible to cross compile Qt in one go (just like we do with >>> qmake)? >> Could you clarify what you mean by "in one go"? >> >> If it's about building host tools as part of the cross-compilation, then no. >> You first have to build a desktop Qt, and re-use that host Qt installation >> for its tools, to cross-compile to another target. >> >> That's been one of the goals for Qt 6 regardless of build system, and has >> been communicated a while ago. > > When I'm cross-compiling Qt for a Linux device, Android, ios, etc., qmake > it's > smart enough to build everything for me: host tools and the libs for that > target in one go i.e. I type ./configure .. && make and it does all the magic > for me. > > How qt modules that have host & target libs will be built with cmake? Like I mentioned in my previous reply, you will have to call configure && make twice, once for the host build and once for target build. And I will reiterate, this has nothing to do with CMake. A decision was made to decouple host builds from target builds, regardless of the build tool used. That magic that you rely on works in 90% cases, and breaks in weird ways for other users, as well as creating a maintenance burden for package maintainers (linux distros, Qt itself, vcpkg, conan, etc) > I'm using qmake for Qt6 when I'm doing Android work, also for this reason. > I don't want to build Qt twice just to use a "cool and superior" build system. Unfortunately that workflow will not work anymore. > > Just out of curiosity, can some pretty please remind me what are the > advantages of using cmake to build Qt over qmake? > I'm not talking about Qt users, for them we should support all (major) build > systems: qmake, cmake, meson, etc. I think those were pointed out and discussed in previous mailing list discussions. Personally i don't want to spend time to try convincing anyone in either direction. There are advantages and disadvantages, as to any solution. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
> On 9. Jun 2020, at 11:36, Edward Welbourne wrote: > > Alexandru Croitor (9 June 2020 10:41) >> I'll acknowledge that the current Qt Creator <-> Build Qt with CMake >> situation is sub-par. > > Is there a P1 ticket open about that ? > Might even warrant P0, given ... I created a bug report here And wrote a public wiki page on how to use Creator to open the Qt CMake projects. It contains the method i tried that worked for me (method 2) and Eike's (method 1). https://bugreports.qt.io/browse/QTCREATORBUG-24159 https://wiki.qt.io/CMake_Port/Qt_Creator ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
Hi, Am Dienstag, 9. Juni 2020, 12:07:02 CEST schrieb Bogdan Vatra via Development: > I'm using qmake for Qt6 when I'm doing Android work, also for this reason. > I don't want to build Qt twice just to use a "cool and superior" build system. > > Just out of curiosity, can some pretty please remind me what are the > advantages of using cmake to build Qt over qmake? > I'm not talking about Qt users, for them we should support all (major) build > systems: qmake, cmake, meson, etc. It seems we have quite different use-cases and workflows because I actually understood that as a useful change - especially the part that Qt no longer weirdly builds for two target (host and actual target) in one go, see my comment here: https://aur.archlinux.org/packages/mingw-w64-qt5-base/#pinned-750114 Additionally: When building only for one target at a time it is always clear to which target compiler flags, linker flags, dependency lookups and so on apply. That removes a lot of complexity from the build system. So far I'm building qmake, bootstrapping libraries and other tools for i686- w64-mingw32, x86_64-w64-mingw32, x86_64-linux-android, arm-linux-androideabi and aarch64-linux-android and in the future maybe for even more targets. In Qt 6 I will be able to save built time on all of these targets by simply making use of the host version of Qt. That sounds like a clear win since the host version of Qt should be available on all platforms I possibly want to build for these targets. The multi-ABI build for Android looks more like a hack to workaround having to build host tools multiple times. It comes with the disadvantage of making the build process more complex. Features which work for other targets like using system provided libraries instead of the bundled ones are likely problematic due to that. At the same time it is limited to Android and not a generic feature. If the goal is to make one Android package which contains binaries built for different targets: Why not simply let androiddeployqt pick up these binaries from different builds? Just allow one to pass multiple install directories/prefixes for these libraries at a time. That sounds way simpler and would also work for other dependencies a project might have besides Qt. Best Regards Marius ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
> -Original Message- > From: Development On Behalf Of > Alexandru Croitor > -> TL;DR here > < > > The CMake Port team wants to switch the main Qt build system to the CMake > one. > > What this means: > > - All Coin qmake configurations in dev branch are removed. > > - Only CMake configurations are built in Coin. > > - CMakeLists.txt files are now the source of truth (no more editing of .pro / > .pri > files). > > - All qmake .pro / .pri files of ported repositories under Coin control are > removed. > > - No more pro2cmake.py and configurejson2cmake.py usage (except for an > initial port of a yet un-ported repository) > > - You need CMake to build Qt. > > - Un-ported repositories should still be able to build with qmake against a > CMake > built Qt (this was tested to work for qtwebengine, but not other repositories, > there are a few known issues left that we're currently fixing). Could you share details how this is done? Can I assume that existing CI targets for those not activated cmake modules continue to work (despite continuing dependencies.yaml updates)? About 30 out of 50 modules where set to ignore in gitmodules. About half of those 30 modules get very regular updates at the very least to push their dependencies.yaml forward. Often those cases involve porting to new qtbase changes. A lot of those modules have a cmake port in a side branch. When asked about this a few weeks ago why we shouldn't merge them to dev you stated that you don't have the bandwidth to help people activating them in the CI. Do you suddenly have the bandwidth to help all those module maintainers to port them to cmake or even enable the qmake against CMake Qt? > --> Proposed time of execution: 1st of July <-- > > > I'd like to hear about any Qt development blockers that you foresee due to > this > change. Will you create test/configuration parity in the CI? Currently the CMake configurations don't even cover all the config options we support via qmake. This creates a big long term problem. For example: - there is only on mac build one cmake -> 3 qmake (drops debug-and-release, drops building examples, no developer build) - Linux QEMU (completely dropped from auto testing) - WebAssembly completely lost - not a single namespace or libinfix build left (afaict) - various other configurations are missing too Unless we can at least convert a couple more CI configurations to cmake it sounds to me we want to save effort on the build system side against a big black box of unknown/not tested problems we won't even notice. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
În ziua de marți, 9 iunie 2020, la 13:46:48 EEST, Edward Welbourne a scris: > On 6/9/20 7:22 AM, Bogdan Vatra via Development wrote: > >>> - if you'll not support/trash all .pro/.pri files how we'll push > >>> fixes for 5.15 branch ? Because right now we can't push fixes > >>> directly to 5.15. branch and all the fixes must go trough dev > >>> branch first. > > În ziua de marți, 9 iunie 2020, la 10:35:33 EEST, Joerg Bornemann a scris: > >> All changes that do not apply to Qt6 must go to 5.15. It's not true > >> that we can't push fixes to 5.15 anymore. > > Bogdan Vatra (9 June 2020 12:12) > > > If I have a fix which involves also changes to some .pr* files, where > > it should go? In dev I can't push it because you nuked the .pr* files, > > in 5.15 I'm banned. > > This is by no means unique to .pr[fio] files: there's lots of code that > we've deleted on dev, that shall need fixes on 5.15. When a fix gets > picked to 5.15, there is a risk that it'll apply and maybe even > integrate; if so, a follow-up commit only on 5.15 can supply the parts > of the change that aren't present on dev. More usually, the pick will > get conflicts or fail to integrate, so you'll get the chance to amend > the picked commit on 5.15. (Even in the first case, if you get the mail > promptly, you can potentially unstage the pick before it gets integrated > and fix it likewise.) > > This applies to all the code that's being deleted on dev, including but > by no means limited to qmake's configuration. > But how can I send a fix to a .pr* file in dev if that file doesn't exists anymore in dev? In this case should we send the patches directly to 5.15. and add the "Cherry-pick: dev" thing to the patch message? Cheers, BogDan. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
> On 2020 Jun 9, at 11:05, Alexandru Croitor wrote: > >> On 9. Jun 2020, at 10:38, Shawn Rutledge wrote: >> >> Well that’s a little extra maintenance work then; I agree that configure is >> nicer, but maybe we can expect the cmake way of configuring to generally be >> more up-to-date if that’s where each change starts. > > Up-to-date how? A new flag is defined to exist when it's available to cmake. But if you say that configure needs work to stay in sync, then maybe that’s delayed? > Are you suggesting modifying upstream cmake to accept things like > --developer-build and map that to -DDEVELOPER_BUILD=ON or something along > those lines? Do you mean cmake could generally try convert unidentified --xxx to -DXXX=ON, or just a few flags that Qt and other projects might agree to use? I guess either way it depends whether such upstream features would be useful to other projects. > I think we'll have to investigate if there's any better way to address > discoverability. One random idea would be to provide a --list-features option > to configure which behind the scenes calls a separate cmake script that finds > and includes all configure.cmake files, collates a list of features and > prints them on the command line. For cmake to be able to read config files and generate a list of possible flags without doing a lot of other work sounds like a useful upstream feature. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
On 6/9/20 7:22 AM, Bogdan Vatra via Development wrote: >>> - if you'll not support/trash all .pro/.pri files how we'll push >>> fixes for 5.15 branch ? Because right now we can't push fixes >>> directly to 5.15. branch and all the fixes must go trough dev >>> branch first. În ziua de marți, 9 iunie 2020, la 10:35:33 EEST, Joerg Bornemann a scris: >> All changes that do not apply to Qt6 must go to 5.15. It's not true >> that we can't push fixes to 5.15 anymore. Bogdan Vatra (9 June 2020 12:12) > If I have a fix which involves also changes to some .pr* files, where > it should go? In dev I can't push it because you nuked the .pr* files, > in 5.15 I'm banned. This is by no means unique to .pr[fio] files: there's lots of code that we've deleted on dev, that shall need fixes on 5.15. When a fix gets picked to 5.15, there is a risk that it'll apply and maybe even integrate; if so, a follow-up commit only on 5.15 can supply the parts of the change that aren't present on dev. More usually, the pick will get conflicts or fail to integrate, so you'll get the chance to amend the picked commit on 5.15. (Even in the first case, if you get the mail promptly, you can potentially unstage the pick before it gets integrated and fix it likewise.) This applies to all the code that's being deleted on dev, including but by no means limited to qmake's configuration. Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
> On Jun 9, 2020, at 12:07, Eike Ziller wrote: > > > >> On Jun 9, 2020, at 09:59, Andy Nichols wrote: >> >> Hi Alexandru, >> >> I think Brett touches on the biggest blocker for me and that is actually >> related to Qt Creators ability to open and use modules built using cmake. I >> am actually really impressed with state of the CMake support for build Qt as >> it is right now, and wish I could more actively use it, but unfortunately my >> current workflow involves using Qt Creator to develop Qt, and I have to work >> on modules that are not just QtBase. Despite adding my cmake based Qt >> Builds to Creator as kits (which seems to only be possible using qmake), it >> isn't possible for Creator to easily recognize that my module's are built >> with that kit when loading them. I hear rumors that it is possible, but >> most of the guys who say that are only working on qtbase anyway. >> >> I think that before we kill the qmake based build of Qt, that our own IDE >> should support developing Qt itself. And I would be happy with some >> "sketchy config" that works with a released version of Qt Creator for now, >> but this shouldn't be good enough to justify killing qmake before a real >> solution is in place. > > Hi, I just tried opening qtdeclarative in Qt Creator 4.12.2 (on macOS). > > 1) build (and install) qtbase with cmake on command line > 2) build (and install) qtdeclarative with cmake on command line (with > qt-cmake && cmake —build .) > 3) register the Qt version in Qt Creator (Pointing it to the qmake that was > built in (1)), press Apply > 4) create a kit with that Qt version in Qt Creator > 5) make sure compiler is set sensibly 5b) make sure the CMake Generator is set correctly > 6) remove everything from the “CMake Configuration” from the kit > 7) open the qtdeclarative/CMakeLists.txt in Qt Creator, check the kit that > you created and change the build directory to qtdeclarative’s build directory > > On a short glance that seemed to work. No code model warnings, triggering a > build triggers a build. > > Step 6 is to try to minimize the fiddling that Qt Creator does with the build > directory. > Whenever Qt Creator says that the “Qt Creator project” and the “cmake build > directory” disagree, choose to “Adapt Qt Creator Project” to the cmake build > directory. > This will hopefully work better in Qt Creator 4.13 where we make Qt Creator > to accept an existing CMake build directory as “the one truth to rule it all”. > > “Importing" the qt/module build into Qt Creator, i.e. automatically creating > a kit from the build indeed doesn’t seem to work. The compiler is empty in > the generated Kit for me, and Qt Creator 4.12 then explicitly passes > CMAKE_CXX_COMPILER=“”. Even though the original CMakeCache.txt contains the > correct entry, and that compiler is actually already registered in Qt Creator. > The Qt version in the kit is empty too. Detecting that seems to be a bit more > difficult, but since CMake gives us the relevant include paths anyhow that > might not be such an issue. > > -- > Eike Ziller > Principal Software Engineer > > The Qt Company GmbH > Erich-Thilo-Straße 10 > D-12489 Berlin > eike.zil...@qt.io > http://qt.io > Geschäftsführer: Mika Pälsi, > Juha Varelius, Mika Harjuaho > Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, > HRB 144331 B -- Eike Ziller Principal Software Engineer The Qt Company GmbH Erich-Thilo-Straße 10 D-12489 Berlin eike.zil...@qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
În ziua de marți, 9 iunie 2020, la 10:35:33 EEST, Joerg Bornemann a scris: > On 6/9/20 7:22 AM, Bogdan Vatra via Development wrote: > > - is it possible to cross compile Qt in one go (just like we do with > > qmake)? > Assuming you're talking about the multi-ABI Android build you've added > to Qt5. This is not yet implemented, but certainly possible with the > Ninja Multi-Config generator that has been added to CMake 3.17 [1]. > > > - if you'll not support/trash all .pro/.pri files how we'll push fixes for > > 5.15 branch ? Because right now we can't push fixes directly to 5.15. > > branch and all the fixes must go trough dev branch first. > > All changes that do not apply to Qt6 must go to 5.15. > It's not true that we can't push fixes to 5.15 anymore. > If I have a fix which involves also changes to some .pr* files, where it should go? In dev I can't push it because you nuked the .pr* files, in 5.15 I'm banned. IMHO we should keep qmake files in place until 6.0.0 it's out. Cheers, BogDan. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
> On Jun 9, 2020, at 09:59, Andy Nichols wrote: > > Hi Alexandru, > > I think Brett touches on the biggest blocker for me and that is actually > related to Qt Creators ability to open and use modules built using cmake. I > am actually really impressed with state of the CMake support for build Qt as > it is right now, and wish I could more actively use it, but unfortunately my > current workflow involves using Qt Creator to develop Qt, and I have to work > on modules that are not just QtBase. Despite adding my cmake based Qt Builds > to Creator as kits (which seems to only be possible using qmake), it isn't > possible for Creator to easily recognize that my module's are built with that > kit when loading them. I hear rumors that it is possible, but most of the > guys who say that are only working on qtbase anyway. > > I think that before we kill the qmake based build of Qt, that our own IDE > should support developing Qt itself. And I would be happy with some "sketchy > config" that works with a released version of Qt Creator for now, but this > shouldn't be good enough to justify killing qmake before a real solution is > in place. Hi, I just tried opening qtdeclarative in Qt Creator 4.12.2 (on macOS). 1) build (and install) qtbase with cmake on command line 2) build (and install) qtdeclarative with cmake on command line (with qt-cmake && cmake —build .) 3) register the Qt version in Qt Creator (Pointing it to the qmake that was built in (1)), press Apply 4) create a kit with that Qt version in Qt Creator 5) make sure compiler is set sensibly 6) remove everything from the “CMake Configuration” from the kit 7) open the qtdeclarative/CMakeLists.txt in Qt Creator, check the kit that you created and change the build directory to qtdeclarative’s build directory On a short glance that seemed to work. No code model warnings, triggering a build triggers a build. Step 6 is to try to minimize the fiddling that Qt Creator does with the build directory. Whenever Qt Creator says that the “Qt Creator project” and the “cmake build directory” disagree, choose to “Adapt Qt Creator Project” to the cmake build directory. This will hopefully work better in Qt Creator 4.13 where we make Qt Creator to accept an existing CMake build directory as “the one truth to rule it all”. “Importing" the qt/module build into Qt Creator, i.e. automatically creating a kit from the build indeed doesn’t seem to work. The compiler is empty in the generated Kit for me, and Qt Creator 4.12 then explicitly passes CMAKE_CXX_COMPILER=“”. Even though the original CMakeCache.txt contains the correct entry, and that compiler is actually already registered in Qt Creator. The Qt version in the kit is empty too. Detecting that seems to be a bit more difficult, but since CMake gives us the relevant include paths anyhow that might not be such an issue. -- Eike Ziller Principal Software Engineer The Qt Company GmbH Erich-Thilo-Straße 10 D-12489 Berlin eike.zil...@qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
Hi, În ziua de marți, 9 iunie 2020, la 11:13:21 EEST, Alexandru Croitor a scris: > > On 9. Jun 2020, at 07:22, Bogdan Vatra wrote: > > > > - is it possible to cross compile Qt in one go (just like we do with > > qmake)? > Could you clarify what you mean by "in one go"? > > If it's about building host tools as part of the cross-compilation, then no. > You first have to build a desktop Qt, and re-use that host Qt installation > for its tools, to cross-compile to another target. > > That's been one of the goals for Qt 6 regardless of build system, and has > been communicated a while ago. When I'm cross-compiling Qt for a Linux device, Android, ios, etc., qmake it's smart enough to build everything for me: host tools and the libs for that target in one go i.e. I type ./configure .. && make and it does all the magic for me. How qt modules that have host & target libs will be built with cmake? I'm using qmake for Qt6 when I'm doing Android work, also for this reason. I don't want to build Qt twice just to use a "cool and superior" build system. Just out of curiosity, can some pretty please remind me what are the advantages of using cmake to build Qt over qmake? I'm not talking about Qt users, for them we should support all (major) build systems: qmake, cmake, meson, etc. Cheers, BogDan. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
Hi, "Putting that aside, how long should we wait then? " is exactly the question we would like to find the answer to __ My own preference is to make the switch to CMake as soon as possible and use effort to improving the CMake port instead of keeping the qmake as a parallel build system for Qt itself. Having the mixing support as an option is beneficial, and something we wanted to offer to the extent feasible without risking the overall Qt 6.0 development. We are currently at a point where all the most commonly used modules are built with CMake. There is a bit less than 3 months to Qt 6.0 feature freeze and around 8 months to Qt 6.1 feature freeze. This should be adequate time to make the changes in all the relevant modules. The goal is for all the Qt 6.0 modules are in place at the Structure and platform freeze milestone (end of June, https://wiki.qt.io/Qt_6.0_Release). This allows us to have things ready well before the feature freeze - and avoid situations where some larger changes are done close to the FF deadline, potentially causing instability. We should not accept any modules that are still built with qmake to the Qt 6.0 release content. So, let's continue the discussion and aim to reach the conclusion in the next few days for the best path forward related to the topic. Yours, Tuukka On 9.6.2020, 11.45, "Development on behalf of Alexandru Croitor" wrote: Hi Andy, I'll acknowledge that the current Qt Creator <-> Build Qt with CMake situation is sub-par. Though, I believe there is a sketchy config to allow you to use a released Qt Creator to develop Qt. Putting that aside, how long should we wait then? I'm not sure if we can afford to delay the switch for much longer, for many reasons: - I don't know how long it would take to improve Creator to do "the right thing". - The Qt releasing team needs to start creating and testing packages based on the CMake-built Qt - Developers are burdened with maintaining 2 build systems (not just the CMake port team, but also other developers doing regular Qt6.0 work) We have to bite the bullet at some point. > On 9. Jun 2020, at 09:59, Andy Nichols wrote: > > Hi Alexandru, > > I think Brett touches on the biggest blocker for me and that is actually related to Qt Creators ability to open and use modules built using cmake. I am actually really impressed with state of the CMake support for build Qt as it is right now, and wish I could more actively use it, but unfortunately my current workflow involves using Qt Creator to develop Qt, and I have to work on modules that are not just QtBase. Despite adding my cmake based Qt Builds to Creator as kits (which seems to only be possible using qmake), it isn't possible for Creator to easily recognize that my module's are built with that kit when loading them. I hear rumors that it is possible, but most of the guys who say that are only working on qtbase anyway. > > I think that before we kill the qmake based build of Qt, that our own IDE should support developing Qt itself. And I would be happy with some "sketchy config" that works with a released version of Qt Creator for now, but this shouldn't be good enough to justify killing qmake before a real solution is in place. ___ 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] Switch the main "Qt Build System"
Alexandru Croitor (9 June 2020 10:41) > I'll acknowledge that the current Qt Creator <-> Build Qt with CMake > situation is sub-par. Is there a P1 ticket open about that ? Might even warrant P0, given ... > We have to bite the bullet at some point. In particular, the "Structure and platform freeze" at the end of June is only three weeks away. I'm guessing we need Coin migrated to CMake by then. We need CMake to be the usual mode of development by then. Notably including: for those using Qt Creator ... Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
> On 9. Jun 2020, at 10:38, Shawn Rutledge wrote: > > Well that’s a little extra maintenance work then; I agree that configure is > nicer, but maybe we can expect the cmake way of configuring to generally be > more up-to-date if that’s where each change starts. Up-to-date how? Are you suggesting modifying upstream cmake to accept things like --developer-build and map that to -DDEVELOPER_BUILD=ON or something along those lines? > >> Indeed currently you need to run CMake at least once to get all the >> checkboxes. I have an idea of how we might improve that (so you don't have >> to run it once) but it's not done yet. > > Do you want to explain? It appears I was mistaken. I was under the impression that the CMake Gui can show some options before doing "configure" at least once, but it doesn't seem to be the case. Some details about that here https://gitlab.kitware.com/cmake/cmake/-/issues/17083 I think we'll have to investigate if there's any better way to address discoverability. One random idea would be to provide a --list-features option to configure which behind the scenes calls a separate cmake script that finds and includes all configure.cmake files, collates a list of features and prints them on the command line. > >>> Will we keep using the configure.json files and generating configure.cmake >>> from them? >> >> It's possible, but it might make sense to to use configure.cmake as the >> source of truth as well. I don't believe we discussed that internally yet. > > At least json is easier to parse, if we try to write other tooling. That's true. But using tooling to forever generate cmake files from json also comes with its downsides (maintenance, inability to express certain constructs, people forgetting to use it, etc). For the last one you could introduce more tooling like a sanity bot check that a cmake file always needs to be generated if a .json file got touched, but that might have false positives, etc. Personally I think having one source of truth is better. And I think tooling for parsing cmake files will appear in time as well. > > ___ > 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] Switch the main "Qt Build System"
Hi Andy, I'll acknowledge that the current Qt Creator <-> Build Qt with CMake situation is sub-par. Though, I believe there is a sketchy config to allow you to use a released Qt Creator to develop Qt. Putting that aside, how long should we wait then? I'm not sure if we can afford to delay the switch for much longer, for many reasons: - I don't know how long it would take to improve Creator to do "the right thing". - The Qt releasing team needs to start creating and testing packages based on the CMake-built Qt - Developers are burdened with maintaining 2 build systems (not just the CMake port team, but also other developers doing regular Qt6.0 work) We have to bite the bullet at some point. > On 9. Jun 2020, at 09:59, Andy Nichols wrote: > > Hi Alexandru, > > I think Brett touches on the biggest blocker for me and that is actually > related to Qt Creators ability to open and use modules built using cmake. I > am actually really impressed with state of the CMake support for build Qt as > it is right now, and wish I could more actively use it, but unfortunately my > current workflow involves using Qt Creator to develop Qt, and I have to work > on modules that are not just QtBase. Despite adding my cmake based Qt Builds > to Creator as kits (which seems to only be possible using qmake), it isn't > possible for Creator to easily recognize that my module's are built with that > kit when loading them. I hear rumors that it is possible, but most of the > guys who say that are only working on qtbase anyway. > > I think that before we kill the qmake based build of Qt, that our own IDE > should support developing Qt itself. And I would be happy with some "sketchy > config" that works with a released version of Qt Creator for now, but this > shouldn't be good enough to justify killing qmake before a real solution is > in place. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
> On 2020 Jun 9, at 10:21, Alexandru Croitor wrote: > >> On 9. Jun 2020, at 09:27, Shawn Rutledge wrote: >> >> FWIW the configuration mechanism seems a bit less friendly so far with all >> those -DSHOUTED options like -DFEATURE_developer_build=ON instead of >> configure -developer-build. But there is cmake-gui, which generates >> checkboxes for all the options after you have run cmake the first time. >> They are even searchable. Is that a recommended way to discover the >> configure options? (Too bad you have to run cmake twice then. > > Joerg already answered about this. > > At least in my opinion, I think we should keep configure script because it's > a nice developer interface. Some mappings are currently missing, but people > could help us out there. Well that’s a little extra maintenance work then; I agree that configure is nicer, but maybe we can expect the cmake way of configuring to generally be more up-to-date if that’s where each change starts. > Indeed currently you need to run CMake at least once to get all the > checkboxes. I have an idea of how we might improve that (so you don't have to > run it once) but it's not done yet. Do you want to explain? >> Will we keep using the configure.json files and generating configure.cmake >> from them? > > It's possible, but it might make sense to to use configure.cmake as the > source of truth as well. I don't believe we discussed that internally yet. At least json is easier to parse, if we try to write other tooling. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
Opening the root qt5/CMakeLists.txt has worked fine for me to work on e.g. qt3d through QtCreator - did not really notice any performance penalty from opening the whole project (except the initial "configure" step). Kind regards, Jean-Michaël <http://www.jcelerier.name> On Tue, Jun 9, 2020 at 10:05 AM Andy Nichols wrote: > Hi Alexandru, > > I think Brett touches on the biggest blocker for me and that is actually > related to Qt Creators ability to open and use modules built using cmake. > I am actually really impressed with state of the CMake support for build Qt > as it is right now, and wish I could more actively use it, but > unfortunately my current workflow involves using Qt Creator to develop Qt, > and I have to work on modules that are not just QtBase. Despite adding my > cmake based Qt Builds to Creator as kits (which seems to only be possible > using qmake), it isn't possible for Creator to easily recognize that my > module's are built with that kit when loading them. I hear rumors that it > is possible, but most of the guys who say that are only working on qtbase > anyway. > > I think that before we kill the qmake based build of Qt, that our own IDE > should support developing Qt itself. And I would be happy with some > "sketchy config" that works with a released version of Qt Creator for now, > but this shouldn't be good enough to justify killing qmake before a real > solution is in place. > > Regards, > Andy Nichols > > -Original Message- > From: Development On Behalf Of > Stottlemyer, Brett (B.S.) > Sent: Monday, June 8, 2020 6:48 PM > To: Alexandru Croitor > Cc: Qt development mailing list > Subject: Re: [Development] Switch the main "Qt Build System" > > Hi Alexandru, > > Thanks for the quick reply. > > On 6/8/20, 12:09 PM, "Alexandru Croitor" wrote: > > The current CMake configurations can be found in > qt5.git/coin/platform_configs/qtsvg.yaml (and many other .yaml files there, > it's just copy-pasted). > > Ahh, I didn't understand what these module specific versions were for. I > guess you download the dependencies (like qtbase) with the expected sha and > same config, rather than building again? That makes sense. > > There was an email on the development list about qt 6.0 module > inclusion. > https://clicktime.symantec.com/3Y88fCHSqah7h6p9gH8GzbV7Vc?u=https%3A%2F%2Fwiki.qt.io%2FChecklist_for_Qt_6.0_inclusion > > Yes, I'm aware. That's where I see a lot of modules with no response or > NOT READY as the status. > > If the module is not included (no cmake port), you can start using the > dependencies.yaml mechanism to pin which sha1s of qtbase, declarative, etc > to use, and continue building against those sha1s with qmake. Of course > once the .pro files in qtbase are gone, you will be stuck to the last set > of SHA1s that still have the .pro files. See dependencies.yaml in > qtquickcontrols2.git for example. > > We have a qmake mixing mechanism (build qtremoteobjects with qmake > against a qtbase built with CMake), but it's not 100% ready yet (the known > issues are being fixed), and thus modules could continue to build with > qmake against even newer sha1s, but I wouldn't bet too much on this > approach (we tried our best to make it work, but there are bound to be > corner cases even after we fix the known issues). > > I'll suggest "qmake mixing" be a prerequisite to flipping the switch to > cmake. It is hard enough to port to Qt6 with the binary > incompatibilities. If you make the build system side of this too painful > as well, you risk modules not being carried to Qt6. I know it is a > different topic, but I am unable to open a developer build of qtbase (from > cmake) in QtCreator - it wants to configure the project again (not to > mention trying to get Ninja in the path for QtC on mac). This all makes it > hard to be an "early adopter", but doing the work later means you have to > tackle all of these issues at once. Without CI, presumably, after this > change (at least for modules). > > I'm not arguing against the change, just want you guys to keep in mind > what this is like for those of us that haven't been developing in Qt6 from > the start. > > Thanks, > Brett > > ___ > 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 > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
> On 9. Jun 2020, at 10:17, Jean-Michaël Celerier > wrote: > > To simplify this step, is there / could there be maybe a > -DQT_BUILD_TOOLS_ONLY that would just generate... well, moc, uic, rcc and a > couple other friends required for a cross-build ? I think that should technically be possible, but I have doubts about it. Not all tools are "bootstrap" tools anymore, which means for uic you need to build QtCore (same for qmake actually). I think qtdeclarative has tools that depend on QtQml. So you'll have to have this weird hybrid of a Qt installation that needs to be maintained to work. > > Best, > Jean-Michaël > > > On Tue, Jun 9, 2020 at 10:14 AM Alexandru Croitor > wrote: > > > > On 9. Jun 2020, at 07:22, Bogdan Vatra wrote: > > > > - is it possible to cross compile Qt in one go (just like we do with qmake)? > > Could you clarify what you mean by "in one go"? > > If it's about building host tools as part of the cross-compilation, then no. > You first have to build a desktop Qt, and re-use that host Qt installation > for its tools, to cross-compile to another target. > > That's been one of the goals for Qt 6 regardless of build system, and has > been communicated a while ago. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
> On 9. Jun 2020, at 09:27, Shawn Rutledge wrote: > > FWIW the configuration mechanism seems a bit less friendly so far with all > those -DSHOUTED options like -DFEATURE_developer_build=ON instead of > configure -developer-build. But there is cmake-gui, which generates > checkboxes for all the options after you have run cmake the first time. They > are even searchable. Is that a recommended way to discover the configure > options? (Too bad you have to run cmake twice then. Joerg already answered about this. At least in my opinion, I think we should keep configure script because it's a nice developer interface. Some mappings are currently missing, but people could help us out there. Indeed currently you need to run CMake at least once to get all the checkboxes. I have an idea of how we might improve that (so you don't have to run it once) but it's not done yet. > > There will be no use for running the old configure script anymore then, right? I think we should keep it. > > It will work from the top-level, so we can still do chained builds with all > modules, right? Yes. It's a bug if it doesn't. > If you have done a build without tests or examples at first (for speed), and > then you want to build some specific ones, how do you do that? You can use $qt_prefix/bin/qt-cmake-standalone-test to configure a single test (or subdir of tests), and build with ninja. > > I see the same nice configure summary is still generated, but it would be > nice to keep writing that to a file like the old configure system does, for > later inspection. I agree. > > Will we keep using the configure.json files and generating configure.cmake > from them? It's possible, but it might make sense to to use configure.cmake as the source of truth as well. I don't believe we discussed that internally yet. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
To simplify this step, is there / could there be maybe a -DQT_BUILD_TOOLS_ONLY that would just generate... well, moc, uic, rcc and a couple other friends required for a cross-build ? Best, Jean-Michaël On Tue, Jun 9, 2020 at 10:14 AM Alexandru Croitor wrote: > > > > On 9. Jun 2020, at 07:22, Bogdan Vatra wrote: > > > > - is it possible to cross compile Qt in one go (just like we do with > qmake)? > > Could you clarify what you mean by "in one go"? > > If it's about building host tools as part of the cross-compilation, then > no. You first have to build a desktop Qt, and re-use that host Qt > installation for its tools, to cross-compile to another target. > > That's been one of the goals for Qt 6 regardless of build system, and has > been communicated a while ago. > ___ > 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] Switch the main "Qt Build System"
> On 9. Jun 2020, at 07:22, Bogdan Vatra wrote: > > - is it possible to cross compile Qt in one go (just like we do with qmake)? Could you clarify what you mean by "in one go"? If it's about building host tools as part of the cross-compilation, then no. You first have to build a desktop Qt, and re-use that host Qt installation for its tools, to cross-compile to another target. That's been one of the goals for Qt 6 regardless of build system, and has been communicated a while ago. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
> On 9. Jun 2020, at 04:32, André Pönitz wrote: > > On Mon, Jun 08, 2020 at 01:43:20PM +, Alexandru Croitor wrote: >> [...] >> The CMake ports are built in Coin with the most important configurations >> (Linux, Windows, macOS, Android, iOS, qemu Linux). > > Is there a list of configurations that work/do not work? I'm not sure what your definition of works is. Here you can see the configurations that are rested currently in Coin. https://code.qt.io/cgit/qt/qt5.git/tree/coin/platform_configs/qtsvg.yaml (svg is just an example) So desktop Ubuntu, static qt builds on Suse, macOS framework builds (non-fw also work), Windows MSVC2019, Windows MinGW 8, Android Arm64, iOS arm64. I'm waiting on some updates to switch iOS to simulator_and_device. Android multi-ABI is currently not implemented, and we don't plan to do it for 6.0. We don't have WebAssembly at the moment, but it was tested to work at some point. Not shown here, we also have a Linux embedded arm qemu configuration in Coin for qtbase, which will be expanded to other modules. > Will it be possible to use bisect "all of Qt" with reasonable effort also for > changes > in the time until the transition is complete and the result is stable? E.g. > will > there be clear which state of which module compiles with which state of other > modules > with no or only short non-compilable phases inbetween? If i understand correctly, this touches upon 2 topics. 1) if we remove .pro files, there will be 3 periods of build systems. Before 6.0, you'll have to configure and build with qmake, then a short period where you can build with qmake and somewhat with cmake (depends on how far in the past you go and at what state the cmake port was in that time), and post-removal of .pro files, you'll only be able to build with cmake. I don't think i can give you exact commit sets for that, so yes, it'll probably be painful. 2) dependencies.yaml Which module compiles against which other module seems like a separate concern that is not entirely related to the build system in all cases. Figuring out combos of which module sha1s can be built together is already somewhat of an issue with the current qmake build system, so that part is out of scope for the CMake port team. Are you suggesting we somehow annotate the CMake part of the question? Like "we guarantee you can build qtbase, qtdeclarative, qtquickcontrols2 with CMake with SHAs X Y and Z? I'm not sure how useful that will be, given dev is constantly moving forward. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
Hi Alexandru, I think Brett touches on the biggest blocker for me and that is actually related to Qt Creators ability to open and use modules built using cmake. I am actually really impressed with state of the CMake support for build Qt as it is right now, and wish I could more actively use it, but unfortunately my current workflow involves using Qt Creator to develop Qt, and I have to work on modules that are not just QtBase. Despite adding my cmake based Qt Builds to Creator as kits (which seems to only be possible using qmake), it isn't possible for Creator to easily recognize that my module's are built with that kit when loading them. I hear rumors that it is possible, but most of the guys who say that are only working on qtbase anyway. I think that before we kill the qmake based build of Qt, that our own IDE should support developing Qt itself. And I would be happy with some "sketchy config" that works with a released version of Qt Creator for now, but this shouldn't be good enough to justify killing qmake before a real solution is in place. Regards, Andy Nichols -Original Message- From: Development On Behalf Of Stottlemyer, Brett (B.S.) Sent: Monday, June 8, 2020 6:48 PM To: Alexandru Croitor Cc: Qt development mailing list Subject: Re: [Development] Switch the main "Qt Build System" Hi Alexandru, Thanks for the quick reply. On 6/8/20, 12:09 PM, "Alexandru Croitor" wrote: The current CMake configurations can be found in qt5.git/coin/platform_configs/qtsvg.yaml (and many other .yaml files there, it's just copy-pasted). Ahh, I didn't understand what these module specific versions were for. I guess you download the dependencies (like qtbase) with the expected sha and same config, rather than building again? That makes sense. There was an email on the development list about qt 6.0 module inclusion. https://clicktime.symantec.com/3Y88fCHSqah7h6p9gH8GzbV7Vc?u=https%3A%2F%2Fwiki.qt.io%2FChecklist_for_Qt_6.0_inclusion Yes, I'm aware. That's where I see a lot of modules with no response or NOT READY as the status. If the module is not included (no cmake port), you can start using the dependencies.yaml mechanism to pin which sha1s of qtbase, declarative, etc to use, and continue building against those sha1s with qmake. Of course once the .pro files in qtbase are gone, you will be stuck to the last set of SHA1s that still have the .pro files. See dependencies.yaml in qtquickcontrols2.git for example. We have a qmake mixing mechanism (build qtremoteobjects with qmake against a qtbase built with CMake), but it's not 100% ready yet (the known issues are being fixed), and thus modules could continue to build with qmake against even newer sha1s, but I wouldn't bet too much on this approach (we tried our best to make it work, but there are bound to be corner cases even after we fix the known issues). I'll suggest "qmake mixing" be a prerequisite to flipping the switch to cmake. It is hard enough to port to Qt6 with the binary incompatibilities. If you make the build system side of this too painful as well, you risk modules not being carried to Qt6. I know it is a different topic, but I am unable to open a developer build of qtbase (from cmake) in QtCreator - it wants to configure the project again (not to mention trying to get Ninja in the path for QtC on mac). This all makes it hard to be an "early adopter", but doing the work later means you have to tackle all of these issues at once. Without CI, presumably, after this change (at least for modules). I'm not arguing against the change, just want you guys to keep in mind what this is like for those of us that haven't been developing in Qt6 from the start. Thanks, Brett ___ 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] Switch the main "Qt Build System"
> -Ursprüngliche Nachricht- > Von: Development Im Auftrag von > [...] > To build autotests, -DFEATURE_developer_build=ON will do that right? And > there are also BUILD_TESTING and QT_NO_MAKE_TESTS so what’s the > relationship? It's currently the same as with qt 5: * FEATURE_developer_build does (among other things) enable tests (BUILD_TESTING) by default, for most platforms. * QT_NO_MAKE_TESTS defines whether a default build will build the tests; the default is OFF (so a mere ninja/jom ... will build all tests) Question is whether this is actually what we want in Qt 6, see https://bugreports.qt.io/browse/QTBUG-84471 for some discussion. Regards Kai ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
On 6/9/20 9:27 AM, Shawn Rutledge wrote: FWIW the configuration mechanism seems a bit less friendly so far with all those -DSHOUTED options like -DFEATURE_developer_build=ON instead of configure -developer-build. But there is cmake-gui, which generates checkboxes for all the options after you have run cmake the first time. They are even searchable. Is that a recommended way to discover the configure options? (Too bad you have to run cmake twice then.) AFAICT this is currently the case. A more user-friendly way to discover Qt features is desirable. There will be no use for running the old configure script anymore then, right? The current configure script (on Linux) supports the -cmake switch and maps some (very few) arguments to CMake arguments. Like -feature-bla -DFEATURE_bla=ON It seems that the classical configure interface is much nicer, especially for people who already know it. Everyone's invited to extend it to map the missing configure options. Same for the Windows configure.bat. It will work from the top-level, so we can still do chained builds with all modules, right? That's the plan. If it doesn't work, it's a bug. To build autotests, -DFEATURE_developer_build=ON will do that right? And there are also BUILD_TESTING and QT_NO_MAKE_TESTS so what’s the relationship? BUILD_TESTING controls whether the tests are configured. In a developer build this is set to ON by default. BUILD_TESTING can be set explicitly to ON to enable tests in non-developer builds. BUILD_TESTING can be set explicitly to OFF to disable tests in developer builds. The description of QT_NO_MAKE_TESTS is: "Should tests be built as part of the default 'all' target." Meaning this variable controls whether tests are build by default. There's also a way to build stand-alone tests with the qt-cmake-standalone-test script in Qt's bin directory. I see the same nice configure summary is still generated, but it would be nice to keep writing that to a file like the old configure system does, for later inspection. True. Will we keep using the configure.json files and generating configure.cmake from them? For now, the configure.json files are kept. Then maybe we could write a better gui later on, that can show checkboxes before you run cmake the first time. It could probably be a pure-qml implementation if we add a QProcess API (which a couple people have already tried to do over the years). It could even have particle effects! Joerg ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
> On 8. Jun 2020, at 18:47, Stottlemyer, Brett (B.S.) wrote: > > Hi Alexandru, > > Thanks for the quick reply. > > On 6/8/20, 12:09 PM, "Alexandru Croitor" wrote: > >The current CMake configurations can be found in > qt5.git/coin/platform_configs/qtsvg.yaml (and many other .yaml files there, > it's just copy-pasted). > > Ahh, I didn't understand what these module specific versions were for. I > guess you download the dependencies (like qtbase) with the expected sha and > same config, rather than building again? That makes sense. The qtfoo.yaml files are used to declare the configuration (OS / compiler / arch) + configure flags. Those are used to configure qtbase, and build the rest of the dependencies, including your own module. The dependencies.yaml declares which sha1s of each repo to use. You can combine these to do whatever your module needs (extra configurations to test added or removed, specific sha1s). > >There was an email on the development list about qt 6.0 module inclusion. > https://clicktime.symantec.com/3Y88fCHSqah7h6p9gH8GzbV7Vc?u=https%3A%2F%2Fwiki.qt.io%2FChecklist_for_Qt_6.0_inclusion > > Yes, I'm aware. That's where I see a lot of modules with no response or NOT > READY as the status. > >If the module is not included (no cmake port), you can start using the > dependencies.yaml mechanism to pin which sha1s of qtbase, declarative, etc to > use, and continue building against those sha1s with qmake. Of course once the > .pro files in qtbase are gone, you will be stuck to the last set of SHA1s > that still have the .pro files. See dependencies.yaml in qtquickcontrols2.git > for example. > >We have a qmake mixing mechanism (build qtremoteobjects with qmake against > a qtbase built with CMake), but it's not 100% ready yet (the known issues are > being fixed), and thus modules could continue to build with qmake against > even newer sha1s, but I wouldn't bet too much on this approach (we tried our > best to make it work, but there are bound to be corner cases even after we > fix the known issues). > > I'll suggest "qmake mixing" be a prerequisite to flipping the switch to > cmake. It is hard enough to port to Qt6 with the binary incompatibilities. > If you make the build system side of this too painful as well, you risk > modules not being carried to Qt6. I know it is a different topic, but I am > unable to open a developer build of qtbase (from cmake) in QtCreator - it > wants to configure the project again (not to mention trying to get Ninja in > the path for QtC on mac). This all makes it hard to be an "early adopter", > but doing the work later means you have to tackle all of these issues at > once. Without CI, presumably, after this change (at least for modules). I completely sympathise with the pain of porting. But we have to be pragmatic. qmake mixing has been a goal for a long while, and we have spent an exorbitant amount of time on it, which in hindsight i think would have been better spent on the CMake port itself. We are fixing the known qmake mixing issues, and hopefully that can cover the usual cases. Unfortunately we can't spend more time on this due to limited time till Qt 6.0 release. Note that qmake mixing is not officially supported in the long run. qmake will support building applications and libraries, but not qt modules (qt_module.prf and friends). Otherwise we basically have to maintain two build system infrastructures (which we want to get away from). Also note that developers were given time to port to CMake. And everyone that got stuck somewhere and needed help always received it (you are welcome at the #qt-cmake freenode channel). I know Qt Creator currently has some quirks with the CMake workflow as well as the environment issues on macOS, but I can confirm that opening qtbase and friends is possible in Creator, albeit requiring some fiddling. > > I'm not arguing against the change, just want you guys to keep in mind what > this is like for those of us that haven't been developing in Qt6 from the > start. > > Thanks, > Brett > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
On Tue, 9 Jun 2020 at 10:35, Ville Voutilainen wrote: > > On Tue, 9 Jun 2020 at 10:29, Shawn Rutledge wrote: > > > > FWIW the configuration mechanism seems a bit less friendly so far with all > > those -DSHOUTED options like -DFEATURE_developer_build=ON instead of > > configure -developer-build. But there is cmake-gui, which generates > > checkboxes for all the options after you have run cmake the first time. > > They are even searchable. Is that a recommended way to discover the > > configure options? (Too bad you have to run cmake twice then.) > > > > There will be no use for running the old configure script anymore then, > > right? > > Last I looked, the configure script can configure a cmake build; it > doesn't support all the options for cmake > that it supports for qmake, but configure -developer-build certainly > worked the last time I checked. I mean configure -cmake -developer-build, of course :P ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
On Tue, 9 Jun 2020 at 10:29, Shawn Rutledge wrote: > > FWIW the configuration mechanism seems a bit less friendly so far with all > those -DSHOUTED options like -DFEATURE_developer_build=ON instead of > configure -developer-build. But there is cmake-gui, which generates > checkboxes for all the options after you have run cmake the first time. They > are even searchable. Is that a recommended way to discover the configure > options? (Too bad you have to run cmake twice then.) > > There will be no use for running the old configure script anymore then, right? Last I looked, the configure script can configure a cmake build; it doesn't support all the options for cmake that it supports for qmake, but configure -developer-build certainly worked the last time I checked. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
On 6/9/20 7:22 AM, Bogdan Vatra via Development wrote: - is it possible to cross compile Qt in one go (just like we do with qmake)? Assuming you're talking about the multi-ABI Android build you've added to Qt5. This is not yet implemented, but certainly possible with the Ninja Multi-Config generator that has been added to CMake 3.17 [1]. - if you'll not support/trash all .pro/.pri files how we'll push fixes for 5.15 branch ? Because right now we can't push fixes directly to 5.15. branch and all the fixes must go trough dev branch first. All changes that do not apply to Qt6 must go to 5.15. It's not true that we can't push fixes to 5.15 anymore. BR, Joerg [1] https://blog.kitware.com/multi-config-ninja-generator-in-cmake-3-17/ ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
FWIW the configuration mechanism seems a bit less friendly so far with all those -DSHOUTED options like -DFEATURE_developer_build=ON instead of configure -developer-build. But there is cmake-gui, which generates checkboxes for all the options after you have run cmake the first time. They are even searchable. Is that a recommended way to discover the configure options? (Too bad you have to run cmake twice then.) There will be no use for running the old configure script anymore then, right? It will work from the top-level, so we can still do chained builds with all modules, right? To build autotests, -DFEATURE_developer_build=ON will do that right? And there are also BUILD_TESTING and QT_NO_MAKE_TESTS so what’s the relationship? If you have done a build without tests or examples at first (for speed), and then you want to build some specific ones, how do you do that? I see the same nice configure summary is still generated, but it would be nice to keep writing that to a file like the old configure system does, for later inspection. Will we keep using the configure.json files and generating configure.cmake from them? Then maybe we could write a better gui later on, that can show checkboxes before you run cmake the first time. It could probably be a pure-qml implementation if we add a QProcess API (which a couple people have already tried to do over the years). ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
Hi, I have a few questions: - is it possible to cross compile Qt in one go (just like we do with qmake)? - if you'll not support/trash all .pro/.pri files how we'll push fixes for 5.15 branch ? Because right now we can't push fixes directly to 5.15. branch and all the fixes must go trough dev branch first. Cheers, BogDan. În ziua de luni, 8 iunie 2020, la 16:43:20 EEST, Alexandru Croitor a scris: > Hi everyone, > > It's time to talk about everyone's favourite topic again: build systems. > > It's been a while since we started porting and merging the CMake ports of Qt > repositories into the dev branches. > > To be precise: qtbase got merged on the 7th of February. > > Since then, all the enabled repositories in qt5.git/dev have CMake ports > merged to their corresponding dev branches (except for qtqa which got > reverted, but it should be back soon). > > The CMake ports are built in Coin with the most important configurations > (Linux, Windows, macOS, Android, iOS, qemu Linux). > > Currently, failed tests don't fail integrations, but we're fixing up the > last failing tests and intend to enforce successful test passing for CMake > configurations. > > Anyway, it's time for the next step. > > > -> TL;DR here > < > > The CMake Port team wants to switch the main Qt build system to the CMake > one. > > What this means: > > - All Coin qmake configurations in dev branch are removed. > > - Only CMake configurations are built in Coin. > > - CMakeLists.txt files are now the source of truth (no more editing of .pro > / .pri files). > > - All qmake .pro / .pri files of ported repositories under Coin control are > removed. > > - No more pro2cmake.py and configurejson2cmake.py usage (except for an > initial port of a yet un-ported repository) > > - You need CMake to build Qt. > > - Un-ported repositories should still be able to build with qmake against a > CMake built Qt (this was tested to work for qtwebengine, but not other > repositories, there are a few known issues left that we're currently > fixing). > > > --> Proposed time of execution: 1st of July <-- > > > I'd like to hear about any Qt development blockers that you foresee due to > this change. > > > Regards, > Alexandru. > ___ > 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] Switch the main "Qt Build System"
Hi Alexandru, Thanks for the quick reply. On 6/8/20, 12:09 PM, "Alexandru Croitor" wrote: The current CMake configurations can be found in qt5.git/coin/platform_configs/qtsvg.yaml (and many other .yaml files there, it's just copy-pasted). Ahh, I didn't understand what these module specific versions were for. I guess you download the dependencies (like qtbase) with the expected sha and same config, rather than building again? That makes sense. There was an email on the development list about qt 6.0 module inclusion. https://clicktime.symantec.com/3Y88fCHSqah7h6p9gH8GzbV7Vc?u=https%3A%2F%2Fwiki.qt.io%2FChecklist_for_Qt_6.0_inclusion Yes, I'm aware. That's where I see a lot of modules with no response or NOT READY as the status. If the module is not included (no cmake port), you can start using the dependencies.yaml mechanism to pin which sha1s of qtbase, declarative, etc to use, and continue building against those sha1s with qmake. Of course once the .pro files in qtbase are gone, you will be stuck to the last set of SHA1s that still have the .pro files. See dependencies.yaml in qtquickcontrols2.git for example. We have a qmake mixing mechanism (build qtremoteobjects with qmake against a qtbase built with CMake), but it's not 100% ready yet (the known issues are being fixed), and thus modules could continue to build with qmake against even newer sha1s, but I wouldn't bet too much on this approach (we tried our best to make it work, but there are bound to be corner cases even after we fix the known issues). I'll suggest "qmake mixing" be a prerequisite to flipping the switch to cmake. It is hard enough to port to Qt6 with the binary incompatibilities. If you make the build system side of this too painful as well, you risk modules not being carried to Qt6. I know it is a different topic, but I am unable to open a developer build of qtbase (from cmake) in QtCreator - it wants to configure the project again (not to mention trying to get Ninja in the path for QtC on mac). This all makes it hard to be an "early adopter", but doing the work later means you have to tackle all of these issues at once. Without CI, presumably, after this change (at least for modules). I'm not arguing against the change, just want you guys to keep in mind what this is like for those of us that haven't been developing in Qt6 from the start. Thanks, Brett ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
Hi, Replying inline. > On 8. Jun 2020, at 17:53, Stottlemyer, Brett (B.S.) wrote: > > Hi Alexandru, > > On 6/8/20, 9:45 AM, "Development on behalf of Alexandru Croitor" > > wrote: > >The CMake ports are built in Coin with the most important configurations > (Linux, Windows, macOS, Android, iOS, qemu Linux). > > Are the "official" cmake configs for CI in the qt5 git repo yet > (https://code.qt.io/cgit/qt/qt5.git/tree/coin/platform_configs)? It would be > nice to be able to mimic those to the extent possible. Depends on how you define official. The current CMake configurations can be found in qt5.git/coin/platform_configs/qtsvg.yaml (and many other .yaml files there, it's just copy-pasted). They are not in qt5.yaml (so the qt5.git product), because there's a Coin issue we are waiting to be fixed. In most cases we try to mimic the qmake Packaging configurations. If qtremoteobjects wants a CI tested cmake configuration, it's enough to copy qtsvg.yaml, and rename it to qtremoteobjects.yaml. You'll have to poke people to schedule test builds though (because we shouldn't merge such a configuration until we confirm it actually builds, otherwise it will block all further commits). > > Also, it looked like there were (last I checked) a bunch of modules not ready > for Qt6 (including my own QtRemoteObjects). What will this mean for those > that need to convert to cmake still? There was an email on the development list about qt 6.0 module inclusion. https://wiki.qt.io/Checklist_for_Qt_6.0_inclusion If there's no cmake port ready, most likely the module will not be included for Qt 6.0. Currently all repos that are not marked with status = ignore in qt5.git/.gitmodules have a cmake port, and are thus included. If the module is not included (no cmake port), you can start using the dependencies.yaml mechanism to pin which sha1s of qtbase, declarative, etc to use, and continue building against those sha1s with qmake. Of course once the .pro files in qtbase are gone, you will be stuck to the last set of SHA1s that still have the .pro files. See dependencies.yaml in qtquickcontrols2.git for example. We have a qmake mixing mechanism (build qtremoteobjects with qmake against a qtbase built with CMake), but it's not 100% ready yet (the known issues are being fixed), and thus modules could continue to build with qmake against even newer sha1s, but I wouldn't bet too much on this approach (we tried our best to make it work, but there are bound to be corner cases even after we fix the known issues). > > Lastly, what are the best sources of help/hints for the conversion? https://wiki.qt.io/CMake_Port/Porting_Guide https://github.com/alcroito/qt6_cmake_port_slides/blob/master/QtCmakePort_ContributorSummit2019.pdf https://code.qt.io/cgit/qt/qtbase.git/tree/cmake/README.md Some of it might be a bit outdated though. > > Regards, > Brett > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
Hi Alexandru, On 6/8/20, 9:45 AM, "Development on behalf of Alexandru Croitor" wrote: The CMake ports are built in Coin with the most important configurations (Linux, Windows, macOS, Android, iOS, qemu Linux). Are the "official" cmake configs for CI in the qt5 git repo yet (https://code.qt.io/cgit/qt/qt5.git/tree/coin/platform_configs)? It would be nice to be able to mimic those to the extent possible. Also, it looked like there were (last I checked) a bunch of modules not ready for Qt6 (including my own QtRemoteObjects). What will this mean for those that need to convert to cmake still? Lastly, what are the best sources of help/hints for the conversion? Regards, Brett ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
Hi, Here's a quick list i collected. https://paste.ubuntu.com/p/Rf44PtzjCS/ You can generate a list for other repos by using the qtbase/util/cmake/pro_conversion_rate.py script. Yes, not 100% of the tests have been ported yet, but the hope is that this can be distributed to other developers, while the CMake port team works on the more infrastructure-related issues. > On 8. Jun 2020, at 15:50, Fabian Kosmale wrote: > > Hi Alexandru, > > first of all, congratulations on the cmake port progress. > But do we have a list of tests which currently only build with qmake? I know > that at least that the tst_moc port hasn't been merged yet, and I doubt that > it's the only one. > > Regards, > Fabian > > -- > Fabian Kosmale > Software Engineer > > The Qt Company GmbH > Erich-Thilo-Str. 10 > D-12489 Berlin > fabian.kosm...@qt.io > +49 1638686070 > http://qt.io > > Geschäftsführer: Mika Pälsi, > Juha Varelius, Mika Harjuaho > Sitz der Gesellschaft: Berlin, > Registergericht: Amtsgericht > Charlottenburg, HRB 144331 B > -- > Von: Development im Auftrag von > Alexandru Croitor > Gesendet: Montag, 8. Juni 2020 15:43 > An: Qt development mailing list > Betreff: [Development] Switch the main "Qt Build System" > > Hi everyone, > > It's time to talk about everyone's favourite topic again: build systems. > > It's been a while since we started porting and merging the CMake ports of Qt > repositories into the dev branches. > > To be precise: qtbase got merged on the 7th of February. > > Since then, all the enabled repositories in qt5.git/dev have CMake ports > merged to their corresponding dev branches (except for qtqa which got > reverted, but it should be back soon). > > The CMake ports are built in Coin with the most important configurations > (Linux, Windows, macOS, Android, iOS, qemu Linux). > > Currently, failed tests don't fail integrations, but we're fixing up the last > failing tests and intend to enforce successful test passing for CMake > configurations. > > Anyway, it's time for the next step. > > > -> TL;DR here > < > > The CMake Port team wants to switch the main Qt build system to the CMake one. > > What this means: > > - All Coin qmake configurations in dev branch are removed. > > - Only CMake configurations are built in Coin. > > - CMakeLists.txt files are now the source of truth (no more editing of .pro / > .pri files). > > - All qmake .pro / .pri files of ported repositories under Coin control are > removed. > > - No more pro2cmake.py and configurejson2cmake.py usage (except for an > initial port of a yet un-ported repository) > > - You need CMake to build Qt. > > - Un-ported repositories should still be able to build with qmake against a > CMake built Qt (this was tested to work for qtwebengine, but not other > repositories, there are a few known issues left that we're currently fixing). > > > --> Proposed time of execution: 1st of July <-- > > > I'd like to hear about any Qt development blockers that you foresee due to > this change. > > > Regards, > Alexandru. > ___ > 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] Switch the main "Qt Build System"
Hi Alexandru, first of all, congratulations on the cmake port progress. But do we have a list of tests which currently only build with qmake? I know that at least that the tst_moc port hasn't been merged yet, and I doubt that it's the only one. Regards, Fabian -- Fabian Kosmale Software Engineer The Qt Company GmbH Erich-Thilo-Str. 10 D-12489 Berlin fabian.kosm...@qt.io +49 1638686070 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Von: Development im Auftrag von Alexandru Croitor Gesendet: Montag, 8. Juni 2020 15:43 An: Qt development mailing list Betreff: [Development] Switch the main "Qt Build System" Hi everyone, It's time to talk about everyone's favourite topic again: build systems. It's been a while since we started porting and merging the CMake ports of Qt repositories into the dev branches. To be precise: qtbase got merged on the 7th of February. Since then, all the enabled repositories in qt5.git/dev have CMake ports merged to their corresponding dev branches (except for qtqa which got reverted, but it should be back soon). The CMake ports are built in Coin with the most important configurations (Linux, Windows, macOS, Android, iOS, qemu Linux). Currently, failed tests don't fail integrations, but we're fixing up the last failing tests and intend to enforce successful test passing for CMake configurations. Anyway, it's time for the next step. -> TL;DR here < The CMake Port team wants to switch the main Qt build system to the CMake one. What this means: - All Coin qmake configurations in dev branch are removed. - Only CMake configurations are built in Coin. - CMakeLists.txt files are now the source of truth (no more editing of .pro / .pri files). - All qmake .pro / .pri files of ported repositories under Coin control are removed. - No more pro2cmake.py and configurejson2cmake.py usage (except for an initial port of a yet un-ported repository) - You need CMake to build Qt. - Un-ported repositories should still be able to build with qmake against a CMake built Qt (this was tested to work for qtwebengine, but not other repositories, there are a few known issues left that we're currently fixing). --> Proposed time of execution: 1st of July <-- I'd like to hear about any Qt development blockers that you foresee due to this change. Regards, Alexandru. ___ 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
[Development] Switch the main "Qt Build System"
Hi everyone, It's time to talk about everyone's favourite topic again: build systems. It's been a while since we started porting and merging the CMake ports of Qt repositories into the dev branches. To be precise: qtbase got merged on the 7th of February. Since then, all the enabled repositories in qt5.git/dev have CMake ports merged to their corresponding dev branches (except for qtqa which got reverted, but it should be back soon). The CMake ports are built in Coin with the most important configurations (Linux, Windows, macOS, Android, iOS, qemu Linux). Currently, failed tests don't fail integrations, but we're fixing up the last failing tests and intend to enforce successful test passing for CMake configurations. Anyway, it's time for the next step. -> TL;DR here < The CMake Port team wants to switch the main Qt build system to the CMake one. What this means: - All Coin qmake configurations in dev branch are removed. - Only CMake configurations are built in Coin. - CMakeLists.txt files are now the source of truth (no more editing of .pro / .pri files). - All qmake .pro / .pri files of ported repositories under Coin control are removed. - No more pro2cmake.py and configurejson2cmake.py usage (except for an initial port of a yet un-ported repository) - You need CMake to build Qt. - Un-ported repositories should still be able to build with qmake against a CMake built Qt (this was tested to work for qtwebengine, but not other repositories, there are a few known issues left that we're currently fixing). --> Proposed time of execution: 1st of July <-- I'd like to hear about any Qt development blockers that you foresee due to this change. Regards, Alexandru. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
