<div dir="ltr"><div dir="ltr">> The world is not spinning around Qt, sorry for the bad news.<div dir="ltr"><br></div><div>On that we agree : <a href="https://www.jetbrains.com/lp/devecosystem-2019/cpp/" target="_blank">https://www.jetbrains.com/lp/devecosystem-2019/cpp/</a></div><div>I mean, I had actual CMake classes with a CMake exam on paper 6 years ago at the university -- you get a few hundreds of new devs on the job market every year out of that one, who *will* know CMake, and won't know qmake / qbs / [...]. <br></div><div><br></div><div><div>> I prefer a transparent self-bootstrapped Qt over an explicit two stages one.</div><div><br></div><div>I (entirely personnally) really do not, - this is anecdotally one of the main objections I've heard about Qt (3k questions just about Qt's configure in SO ! <a href="https://stackoverflow.com/search?q=%5Bqt%5D+configure" target="_blank">https://stackoverflow.com/search?q=%5Bqt%5D+configure</a>) : not just answering to a standard cmake && make && make install which comes with gui discoverability through cmake-gui, embeddability through add_subdirectory or C++ package managers such as conan, vcpkg, hunter, etc etc. but instead acting like its own microcosm library where you have to learn yet another set of commands & invocations if you want to integrate it in your existing system.</div><div><br></div><div>> Last comment: Please think about [...] Cmake is not yet ready for that.<div dir="auto"><br></div><div dir="auto">> embedded Linux</div><div>Oh come on. <br></div><div><br></div><div>> qnx</div><div>you mean like software companies using Qt do, today ? <a href="https://github.com/mapbox/mapbox-gl-native/blob/master/platform/qt/qnx.cmake" target="_blank">https://github.com/mapbox/mapbox-gl-native/blob/master/platform/qt/qnx.cmake</a></div><div><br></div><div>> vxworx</div><div><br></div><div>VxWorks ships with CMake so there must be at least some amount of support. (<a href="https://tp.prosoft.ru/docs/shared/webdav_bizproc_history_get/234075/234075/?ncc=1&force_download=1" target="_blank">https://tp.prosoft.ru/docs/shared/webdav_bizproc_history_get/234075/234075/?ncc=1&force_download=1</a>)</div><div><br></div><div>> iOS</div><div><br></div><div>... yes ? <a href="https://github.com/sheldonth/ios-cmake" target="_blank">https://github.com/sheldonth/ios-cmake</a></div><div>Also, just because CMake now has acquired *official* support for iOS does not mean that it hasn't been working for a long time. There were people shipping iOS apps with CMake five years ago - and this is due in part to CMake having a *large* community, unlike qmake / qbs, which means that even if CMake does not directly support $FEATURE, chances are that you can find an aptly-licensed open-source library that you can use to augment your build with and achieve what you want. <div>See e.g. all the projects that ship today with <a href="https://github.com/leetal/ios-cmake" target="_blank">https://github.com/leetal/ios-cmake</a>, <a href="https://github.com/ruslo/polly" target="_blank">https://github.com/ruslo/polly</a>, etc etc <br></div>In contrast, how many people are shipping qmake extensions outside of QtCore, as a library for anyone to use ?   <br></div><div><br></div><div> > android and whatever next os is coming.</div><div>Oh come on (bis). CMake has been one of the official android build systems for close to two years now : <a href="https://developer.android.com/ndk/guides/cmake" target="_blank">https://developer.android.com/ndk/guides/cmake</a></div><div><br></div><div>Also, C++Builder was able to ship and advertise CMake support for Android & iOS a year ago so there is no reason Qt cannot do the same : <a href="https://community.idera.com/developer-tools/b/blog/posts/new-in-10-2-3-cmake-support-for-ios-and-android" target="_blank">https://community.idera.com/developer-tools/b/blog/posts/new-in-10-2-3-cmake-support-for-ios-and-android</a></div><div dir="auto"><br></div><div dir="auto">>  and whatever next os is coming.</div><div dir="auto"><br></div><div>you mean like Fuschia (<a href="https://github.com/Kitware/CMake/blob/master/Modules/Platform/Fuchsia.cmake" target="_blank">https://github.com/Kitware/CMake/blob/master/Modules/Platform/Fuchsia.cmake</a>) or maybe actual operating systems built with CMake, such as IncludeOS (<a href="https://github.com/includeos/IncludeOS" target="_blank">https://github.com/includeos/IncludeOS</a>) or ReactOS (<a href="https://github.com/reactos/reactos" target="_blank">https://github.com/reactos/reactos</a>) ? :-)</div><div><br></div><div>Best,</div><div>Jean-Michaël<br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 17, 2019 at 11:05 AM Christian Gagneraud <<a href="mailto:chgans@gmail.com" target="_blank">chgans@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 17 Jun 2019, 20:15 Elvis Stansvik, <<a href="mailto:elvstone@gmail.com" rel="noreferrer" target="_blank">elvstone@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Den mån 17 juni 2019 kl 09:12 skrev Christian Gagneraud <<a href="mailto:chgans@gmail.com" rel="noreferrer noreferrer" target="_blank">chgans@gmail.com</a>>:<br>
><br>
> On Mon, 17 Jun 2019, 18:11 Jedrzej Nowacki, <<a href="mailto:Jedrzej.Nowacki@qt.io" rel="noreferrer noreferrer" target="_blank">Jedrzej.Nowacki@qt.io</a>> wrote:<br>
>><br>
>> On Saturday, June 15, 2019 6:37:24 PM CEST Thiago Macieira wrote:<br>
>> > On Saturday, 15 June 2019 02:18:28 PDT Jean-Michaël Celerier wrote:<br>
>> > > You can download a CMake static binary (<a href="https://cmake.org/download/" rel="noreferrer noreferrer noreferrer" target="_blank">https://cmake.org/download/</a>) that<br>
>> ><br>
>> > (...)<br>
>> ><br>
>> > I would prefer that our requirements be present in Linux distributions we<br>
>> > declare are supported build environments. If nothing else, our CI will<br>
>> > benefit from this.<br>
>><br>
>> Let's not pull CI into it. It already<br>
><br>
><br>
> Wow! Let's not pull in the system which only goal is to validate the "supported platforms" promise, is it what you mean?<br>
> If I need a special cmake to build Qt, then this should be shipped as part of Qt itself, another third-party source tree.<br>
> And then it means that I will need to build qt's build system. In other words, I'll have to bootstrap Qt build system.<br>
> I thought that it was a big no-no. The main argument to ditch qmake and qbs...<br>
<br>
Hm, what is the problem with using the official CMake binaries? Isn't<br>
that what you'd do on Windows / macOS anyway?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">In case you didn't follow the thread, building Qt with cmake requires a non-released version of cmake.</div><div dir="auto"><br></div><div dir="auto">The question is:</div><div dir="auto">By the time qt6 will be out, will the requirement of cmake minimum version be met by, say, the latest (two) Ubuntu LTS release? (Or Macos, ...)</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">The answer is that, best case, this is doable if qt6 is not released before 2022 or 2024. (Current req. Is unreleased cmake 2.15. assuming the minimum req. is not bumped, which is very unlikely given the lack of support for Android, iOS, etc...)</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If distro X (e.g. *buntu 20.04) happen to ship a sufficient version<br>
when it arrives, then great. But having to install the build tool from<br>
the vendor instead of the distro package manager surely can't be a<br>
blocker<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Really? Then convince the boot2qt team to force yocto to use the latest bleeding edge cmake version for their stable branch...</div><div dir="auto">Good luck with that.</div><div dir="auto"><br></div><div dir="auto">And then, which is my point, you're asking your customers to build/install Qt build system in order to build Qt itself. </div><div dir="auto">That is wrong. The world is not spinning around Qt, sorry for the bad news.</div><div dir="auto">I prefer a transparent self-bootstrapped Qt over an explicit two stages one.</div><div dir="auto"><br></div><div dir="auto">Right now the cmake build system doesn't respect the initial requirements that were used to ditch contenders.</div><div dir="auto"><br></div><div dir="auto">This is in no way a democratic process. </div><div dir="auto">This is selective hearing, reqs for cmake are artificially lowered while reqs for contenders are artificially raised.</div><div dir="auto"><br></div><div dir="auto">I have no doubt that cmake will be Qt6 build system, this is your choice, I'm just asking to stop this simulation, and I'm asking you to take your responsibilities, if building Qt6 is not supported on mainstream platforms I might consider switching away from Qt.</div><div dir="auto"><br></div><div dir="auto">Last comment: Please think about embedded Linux, qnx, vxworx, iOS, android and whatever next os is coming.</div><div dir="auto">Cmake is not yet ready for that.</div><div dir="auto"><br></div><div dir="auto">Chris</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Elvis<br>
<br>
><br>
> Chris<br>
><br>
><br>
>> covers installation of the cmake in<br>
>> order to test wip/cmake branch (<a href="https://code.qt.io/cgit/qt/qt5.git/tree/coin/" rel="noreferrer noreferrer noreferrer" target="_blank">https://code.qt.io/cgit/qt/qt5.git/tree/coin/</a><br>
>> provisioning/common/linux/cmake_linux.sh?h=wip/cmake)<br>
>><br>
>> Cheers,<br>
>>   Jędrek<br>
>><br>
>><br>
>> _______________________________________________<br>
>> Development mailing list<br>
>> <a href="mailto:Development@qt-project.org" rel="noreferrer noreferrer" target="_blank">Development@qt-project.org</a><br>
>> <a href="https://lists.qt-project.org/listinfo/development" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.qt-project.org/listinfo/development</a><br>
><br>
> _______________________________________________<br>
> Development mailing list<br>
> <a href="mailto:Development@qt-project.org" rel="noreferrer noreferrer" target="_blank">Development@qt-project.org</a><br>
> <a href="https://lists.qt-project.org/listinfo/development" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.qt-project.org/listinfo/development</a><br>
</blockquote></div></div></div>
_______________________________________________<br>
Development mailing list<br>
<a href="mailto:Development@qt-project.org" target="_blank">Development@qt-project.org</a><br>
<a href="https://lists.qt-project.org/listinfo/development" rel="noreferrer" target="_blank">https://lists.qt-project.org/listinfo/development</a><br>
</blockquote></div></div>