17.06.2019, 14:10, "Jean-Michaël Celerier" <jeanmichael.celer...@gmail.com>: >> The world is not spinning around Qt, sorry for the bad news. > > On that we agree : https://www.jetbrains.com/lp/devecosystem-2019/cpp/ > 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 / > [...]. > >> I prefer a transparent self-bootstrapped Qt over an explicit two stages one. > > 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 > ! https://stackoverflow.com/search?q=%5Bqt%5D+configure) : 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.
FWIW, Qt packages are available in Conan and Vcpkg. Also, are you trying to say that cmake's configuration system is more user friendly than Qt's configure (or for, that matter, autotool's configure or similar things in sane build systems)? All of the latter provide a set of documented options with human-oriented names, while cmake's sol;ution is just a fancy editor for cache file which exposes internal variable names as they are. > >> Last comment: Please think about [...] Cmake is not yet ready for that. > >> embedded Linux > Oh come on. > >> qnx > you mean like software companies using Qt do, today ? > https://github.com/mapbox/mapbox-gl-native/blob/master/platform/qt/qnx.cmake > >> vxworx > > VxWorks ships with CMake so there must be at least some amount of support. > (https://tp.prosoft.ru/docs/shared/webdav_bizproc_history_get/234075/234075/?ncc=1&force_download=1) > >> iOS > > ... yes ? https://github.com/sheldonth/ios-cmake > 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. > See e.g. all the projects that ship today with > https://github.com/leetal/ios-cmake, https://github.com/ruslo/polly, etc etc > In contrast, how many people are shipping qmake extensions outside of QtCore, > as a library for anyone to use ? > >> android and whatever next os is coming. > Oh come on (bis). CMake has been one of the official android build systems > for close to two years now : https://developer.android.com/ndk/guides/cmake > > 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 : > https://community.idera.com/developer-tools/b/blog/posts/new-in-10-2-3-cmake-support-for-ios-and-android > >> and whatever next os is coming. > > you mean like Fuschia > (https://github.com/Kitware/CMake/blob/master/Modules/Platform/Fuchsia.cmake) > or maybe actual operating systems built with CMake, such as IncludeOS > (https://github.com/includeos/IncludeOS) or ReactOS > (https://github.com/reactos/reactos) ? :-) > > Best, > Jean-Michaël > > On Mon, Jun 17, 2019 at 11:05 AM Christian Gagneraud <chg...@gmail.com> wrote: >> On Mon, 17 Jun 2019, 20:15 Elvis Stansvik, <elvst...@gmail.com> wrote: >>> Den mån 17 juni 2019 kl 09:12 skrev Christian Gagneraud <chg...@gmail.com>: >>>> >>>> On Mon, 17 Jun 2019, 18:11 Jedrzej Nowacki, <jedrzej.nowa...@qt.io> wrote: >>>>> >>>>> On Saturday, June 15, 2019 6:37:24 PM CEST Thiago Macieira wrote: >>>>> > On Saturday, 15 June 2019 02:18:28 PDT Jean-Michaël Celerier wrote: >>>>> > > You can download a CMake static binary (https://cmake.org/download/) >>>>> > > that >>>>> > >>>>> > (...) >>>>> > >>>>> > I would prefer that our requirements be present in Linux distributions >>>>> > we >>>>> > declare are supported build environments. If nothing else, our CI will >>>>> > benefit from this. >>>>> >>>>> Let's not pull CI into it. It already >>>> >>>> >>>> Wow! Let's not pull in the system which only goal is to validate the >>>> "supported platforms" promise, is it what you mean? >>>> If I need a special cmake to build Qt, then this should be shipped as part >>>> of Qt itself, another third-party source tree. >>>> 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. >>>> I thought that it was a big no-no. The main argument to ditch qmake and >>>> qbs... >>> >>> Hm, what is the problem with using the official CMake binaries? Isn't >>> that what you'd do on Windows / macOS anyway? >> >> In case you didn't follow the thread, building Qt with cmake requires a >> non-released version of cmake. >> >> The question is: >> 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, ...) >> >> 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...) >> >>> If distro X (e.g. *buntu 20.04) happen to ship a sufficient version >>> when it arrives, then great. But having to install the build tool from >>> the vendor instead of the distro package manager surely can't be a >>> blocker >> >> Really? Then convince the boot2qt team to force yocto to use the latest >> bleeding edge cmake version for their stable branch... >> Good luck with that. >> >> And then, which is my point, you're asking your customers to build/install >> Qt build system in order to build Qt itself. >> That is wrong. The world is not spinning around Qt, sorry for the bad news. >> I prefer a transparent self-bootstrapped Qt over an explicit two stages one. >> >> Right now the cmake build system doesn't respect the initial requirements >> that were used to ditch contenders. >> >> This is in no way a democratic process. >> This is selective hearing, reqs for cmake are artificially lowered while >> reqs for contenders are artificially raised. >> >> 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. >> >> Last comment: Please think about embedded Linux, qnx, vxworx, iOS, android >> and whatever next os is coming. >> Cmake is not yet ready for that. >> >> Chris >> >>> Elvis >>> >>>> >>>> Chris >>>> >>>> >>>>> covers installation of the cmake in >>>>> order to test wip/cmake branch >>>>> (https://code.qt.io/cgit/qt/qt5.git/tree/coin/ >>>>> provisioning/common/linux/cmake_linux.sh?h=wip/cmake) >>>>> >>>>> Cheers, >>>>> Jędrek >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 > , > > _______________________________________________ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
