[Development] Proposing CMake as build tool for Qt 6

Mon Jun 17 15:22:01 CEST 2019

> Are you insulting this mailing list?
How do you think we made it so far without cmake? Honestly?

No, and I apologize if my wording was so poor as to make you think that
this was the goal. I am just trying to point out that there are more people
who learn & know CMake than people who learn qmake or QBS, and that is in
my opinion the n°1 concern when designing something with as large-reaching
goals as Qt's : how is it possible to ensure that most people can use it
right from the get go, without having to learn another additional language.
Basically, how do you reach the next N million of programmers ?

> The very fact you're discussing qmake and qbs just show that you know
about them, and that you know what they provide cmake cannot provide
(yet).

My personal experience with qmake has been that I have migrated most of my
projects from it to CMake around cmake 3.2 and did not look back (but oh
boy am I in pain whenever I have to work on a qmake project with > 15
files).
With QBS, it has been mainly of reporting build errors when using it with
openFrameworks and eventually reverting back to makefiles because of how
broken it was. But this was two years or so ago, though the taste it left
in my mouth (especially after promising so much) was fairly sour.

> Yes, come on, why do i have to define a custom "toolchain file" each
time someone fart?

I really don't see the difference with defining a new mkspec (though I
don't know if you can put mkspecs outside of qt's mkspecs folder ; it would
certainly be nice if it was the case especially when /usr/lib/qt is
readonly).

> Can't you just understand the good old gnu configure triplet? Or the
concept of sytem/user wide profile? (qbs profile, qmake specs)

That's personal preferences, but I really don't like to depend too much on
$distro-provided development packages.
I already wasted waaay enough time in my life investigating why development
package $foo does not work the same on ubuntu 12.04 vs 14.04 vs 16.04 vs
18.04 vs archlinux vs fedora vs freebsd.
I may also have been unlucky but never had I to only switch to another
compiler triplet to make cross-compiling work as I wanted it to.

> Why does every single project has to provide it's own set of CMake
toolchain files?
Have you ever thought about the problem?

How do other build systems solve this ? qmake uses mkspecs, qbs uses qbs
modules, meson uses a cross-build file...
What happens when I want to cross-compile for a new, unknown target with
qmake or QBS on Ubuntu ?
How can I add features to them if they don't currently support them - e.g.,
a target to generate doxygen files, or to call gcov & generate a coverage
report, or whatever new-fangled way to run link-time optimizations -,
without patching them, and without adding stuff to my project source tree ?
I don't see how the solution can be fundamentally different from CMake's -
except that CMake has a large library of scripts contributed by people out
there.

All the best,
Jean-Michaël

On Mon, Jun 17, 2019 at 2:27 PM Christian Gagneraud <chgans at gmail.com>
wrote:

> On Mon, 17 Jun 2019 at 23:06, Jean-Michaël Celerier
> <jeanmichael.celerier at gmail.com> wrote:
> >
> > > 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 / [...].
>
> Are you insulting this mailing list?
> How do you think we made it so far without cmake? Honestly?
>
> The very fact you're discussing qmake and qbs just show that you know
> about them, and that you know what they provide cmake cannot provide
> (yet).
>
> > > 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.
>
> Woah, you're ass is so shinny i can't see the light.
>
> > > Last comment: Please think about [...] Cmake is not yet ready for that.
> >
> > > embedded Linux
> > Oh come on.
>
> Yes, come on, why do i have to define a custom "toolchain file" each
> time someone fart?
> Can't you just understand the good old gnu configure triplet? Or the
> concept of sytem/user wide profile? (qbs profile, qmake specs)
> Why does every single project has to provide it's own set of CMake
> toolchain files?
> Have you ever thought about the problem?
>
> Well, i doubt that. "If it works on my Windows machine, then it works
> everywhere", right? (provocative sarcasm really)
>
> > > qnx
> > you mean like software companies using Qt do, today ?
> https://github.com/mapbox/mapbox-gl-native/blob/master/platform/qt/qnx.cmake
>
> I'm gob-smacked!!!
> This is awesome.
>
> They can use gcc to build a QNX app... Thanks CMake to allow QNX to
> exists... This real-time kernel could never have existed without the
> help of CMake.
> My first experience with QNX, was.. at least 20 years ago. I'm not
> even sure CMake existed back at that time.
> But hey, you're revolutionizing the world, i cannot fight obviously...
>
> > > 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
> )
>
> Lol, did you run out of google searches? Honestly i can throw random
> links too. Did you click "I'm felling lucky" or what?
>
> > > iOS
> >
> > ... yes ? https://github.com/sheldonth/ios-cmake
>
> Yeah right, problem solved then! Ship it! Come on, let's do it!
>
> Let's make an announcement:
>
> CMAKE FULLY SUPPORT IOS.
>
> PS: well, not exactly, please carrefully read the small prints.
>
> > 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) ? :-)
>
> Man, your google skills outpace me to such an extent that i cannot be
> bothered wasted more time...
>
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190617/ae2fbd8c/attachment.html>