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] Patching QtWebView to use QtWebkit "rebooted"?
11.06.2020, 01:10, "René J.V. Bertin" : > Hi, > > Suppose I wanted to patch QtWebView so it will use WebKit2 from the rebooted > QtWebKit libraries instead of the QtWebEngine bloatware, how feasible would > that be? A rabbithole, a question of reparenting and changing a limited > number of function calls, or pointless because QtWebKit already has a > QQuickWebView class? Whole point of QtWebView is to use platform specific backends on platforms where they do exist, at the cost of limited API. If you need to use platform-specific backends and want to replace QtWebEngine on platforms with no "native" browser component, it might make sense. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] take five
On Wed, 10 Jun 2020 at 15:26, Lorn Potter wrote: > > Hi *, > On the road to Qt 6, we must remember our past: > What better way than to have a short break to listen to this worldwide > hit - The Qt 4 Dance! > > https://www.youtube.com/watch?v=NbTEVbQLC8s > > -- > Lorn Potter > Freelance Qt Developer. Maintainer QtSensors, Qt WebAssembly That video was unexpectedly enjoyable to watch. Thanks for sharing! Regards, Sze-Howe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Patching QtWebView to use QtWebkit "rebooted"?
Hi, Suppose I wanted to patch QtWebView so it will use WebKit2 from the rebooted QtWebKit libraries instead of the QtWebEngine bloatware, how feasible would that be? A rabbithole, a question of reparenting and changing a limited number of function calls, or pointless because QtWebKit already has a QQuickWebView class? Thanks, R. ___ 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] Documenting Qt 6 API breakages
Hi, FWIW, the page I made just replaced the Qt 4 to Qt 5 porting guide, so I didn't put any thought into whether we should change the existing structure. As long as they are accessible from a general "porting" document, I think it is a good idea to move specifics into their respective modules. That would make it possible to do the documentation as part of the change as well, instead of as an afterthought. Eskil Abrahamsen Blomfeldt Senior Manager, Graphics The Qt Company Sandakerveien 116 0484 Oslo, Norway eskil.abrahamsen-blomfe...@qt.io http://qt.io Fra: Development på vegne av Kai Köhne Sendt: onsdag 27. mai 2020 16:48 Til: development@qt-project.org Emne: [Development] Documenting Qt 6 API breakages Hi, We should start documenting the API changes that Qt 6.0 brings soon. This will allow getting people getting an overview, help early adopters, and will give us time to improve the documentation before the release. Now I see that there are different paths taken: - Eskil and others have started listing changes in a page in the qtdoc repository, https://doc-snapshots.qt.io/qt6-dev/sourcebreaks.html - I created a skeleton for Qt Core changes in the qtbase repository: https://codereview.qt-project.org/c/qt/qtbase/+/299664 . I wasn't aware of the existing page in qtdoc; Anyhow, from past experience I prefer having the documentation nearby the actual code. I therefore would like move the existing sections about Qt Quick, Qt OpenGL to the respective module documentation and let https://doc-snapshots.qt.io/qt6-dev/sourcebreaks.html just link to the module documentation pages. Thoughts? Kai -- Kai Köhne, Director R | The Qt Company The Qt Company GmbH, Erich-Thilo-Straße 10, D-12489 Berlin 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 ___ 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
[Development] The future of Qt Purchasing in Qt 6
Hi! Qt Purchasing is a convenience API for handling in-app purchases on different platforms. Qt 6 will go through lots of changes that affect many modules. It is therefore a good time to reconsider the future of Qt Purchasing API. One potential pitfall of the API is that apps developed with it could suffer from weakened copy protection due to Qt open source nature. For example, platforms like Android recommend doing code obfuscation for the app's source code [1]. It might be possible to replace the app's package with a custom-built Qt Purchasing library and use instead, thus breaking copy protection. Another challenge we have been facing is with the community contributions. By nature, contributions should be cross platform, and if not then at least not break the functionality of another target platform. Following this has proven to be very difficult thus leading to rejection of many submissions to improve Qt Purchasing API. This in turn makes for unhappy contributors, and Qt missing the needed feature. I propose to exclude Qt Purchasing from Qt 6, and instead move the underlying use cases forward as examples, which has the following advantages: · The examples would be easily copy-pasted, improved, obfuscated, and more secure. · They can demonstrate how to use purchasing capabilities for different platforms with their native purchasing APIs (e.g. Android, iOS, WinRT). · They can act as good examples of how Qt users can interact with more advanced platform-specific and native APIs that the core Qt doesn't cover. · Modifications and contributions would be much easier added to an example than to a module which has more restriction such as feature-freezes. · OS-specific features could be added and demonstrated if one feature is available in one OS and not the others. Updates related to this are tracked under the ticket QTBUG-82847. References: [1] https://developer.android.com/google/play/billing/billing_library_overview#Verify-purchase-device Eskil Abrahamsen Blomfeldt Senior Manager, Graphics The Qt Company Sandakerveien 116 0484 Oslo, Norway eskil.abrahamsen-blomfe...@qt.io http://qt.io ___ 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
[Development] take five
Hi *, On the road to Qt 6, we must remember our past: What better way than to have a short break to listen to this worldwide hit - The Qt 4 Dance! https://www.youtube.com/watch?v=NbTEVbQLC8s -- 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 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
