[Development] Qt 6 buildsystem support requirements

[Ray Donnelly]

On Sat, Jul 21, 2018 at 4:42 PM, Jean-Michaël Celerier
<jeanmichael.celerier at gmail.com> wrote:
> That's fairly disingenuous, if not blatantly false. There are, like, 6 .cpp
> files in the CMake repo which provide the Qt-specific commands :
> https://github.com/Kitware/CMake/tree/master/Source (grep for cmQt).
>

What is disingenuous, if not blatantly false? Be specific please.

git clone https://gitlab.kitware.com/cmake/cmake.git

du -csh cmake/Source/cmQt*
8.0K cmake/Source/cmQtAutoGen.cxx
4.0K cmake/Source/cmQtAutoGen.h
 52K cmake/Source/cmQtAutoGenInitializer.cxx
4.0K cmake/Source/cmQtAutoGenInitializer.h
 24K cmake/Source/cmQtAutoGenerator.cxx
 12K cmake/Source/cmQtAutoGenerator.h
 64K cmake/Source/cmQtAutoGeneratorMocUic.cxx
 12K cmake/Source/cmQtAutoGeneratorMocUic.h
 20K cmake/Source/cmQtAutoGeneratorRcc.cxx
4.0K cmake/Source/cmQtAutoGeneratorRcc.h
204K total

I stand corrected, there *used* to be 150K of Qt specific C++ code in
CMake, but since I last checked it's grown to 204K (or perhaps I
counted it less well last time?)

And Giuseppe's devil's advocacy does speak to some of my issues with
CMake (along with it's lack of proper cross compilation support, it
defaulting to looking in *system* folders (which is never what any
non-chrooted distro wants).

Qbs is far better IMHO.

> Besides... why would it matter that they are implemented in C++ instead of
> cmake-lang ? If anything, CMake's automoc is in my experience much faster to
> process the whole repo.
>
> Richard: so what's this then ?
> https://github.com/qbs/qbs/blob/2d1de8cc84b258174b2dc0a8080f549cd9b59b32/src/lib/corelib/buildgraph/qtmocscanner.cpp
>
>
>
> -------
> Jean-Michaël Celerier
> http://www.jcelerier.name
>
> On Sat, Jul 21, 2018 at 4:39 PM, Ray Donnelly <mingw.android at gmail.com>
> wrote:
>>
>> CMake has its own 'language' that was retrofitted after the fact, evolving
>> from a simple definition based system.
>>
>> So why aren't all these special rules written in that 'language' then? 150
>> odd k of qt c++ hacks is what we get instead.
>>
>> On Sat, Jul 21, 2018, 3:26 PM Jean-Michaël Celerier
>> <jeanmichael.celerier at gmail.com> wrote:
>>>
>>> > How much custom c++ code does it contains for just qt?
>>>
>>> which build system which supports automatic calling of moc doesn't have
>>> specific code for qt ?
>>>
>>>
>>>
>>>
>>> -------
>>> Jean-Michaël Celerier
>>> http://www.jcelerier.name
>>>
>>> On Sat, Jul 21, 2018 at 3:48 PM, Ray Donnelly <mingw.android at gmail.com>
>>> wrote:
>>>>
>>>> As someone who works on a cross platform distribution let me tell you
>>>> that cmake is plain terrible. How much custom c++ code does it contains for
>>>> just qt? Loads, absolutely tonnes or rubbish.
>>>>
>>>> On Sat, Jul 21, 2018, 1:49 PM Jean-Michaël Celerier
>>>> <jeanmichael.celerier at gmail.com> wrote:
>>>>>
>>>>> > There is a build system that fulfills all of Thiago's points, and it
>>>>> > is
>>>>> already widely used in the Qt community: CMake.
>>>>>
>>>>> +1, I was flabbergasted when the big objection against CMake in Qt 6
>>>>> boiled down to "it does not supports all the architectures that Qt
>>>>> supports", so instead of contributing them - or hell, even forking CMake for
>>>>> those specific architectures (what are them ? I use cmake for windows, mac,
>>>>> linux, android, ios and the toolchain file allows for a lot of
>>>>> customization), what, create a new build system from scratch that splits the
>>>>> C++ community further ? There would be so much to gain with a better
>>>>> relationship between Qt and CMake.
>>>>>
>>>>> Best,
>>>>> -------
>>>>> Jean-Michaël Celerier
>>>>> http://www.jcelerier.name
>>>>>
>>>>> On Sat, Jul 21, 2018 at 2:42 PM, Kevin Kofler <kevin.kofler at chello.at>
>>>>> wrote:
>>>>>>
>>>>>> Bogdan Vatra via Development wrote:
>>>>>> > Anyway IMHO is more important to have a clean, nice and easy to use
>>>>>> > syntax
>>>>>> > and to be tooling friendly than 1.b.
>>>>>>
>>>>>> A custom build system is always a major pain point for distributions.
>>>>>> A
>>>>>> circular dependency (what Thiago's 1.b forbids) makes it particularly
>>>>>> painful. How should we bootstrap new architectures or entirely new
>>>>>> distributions if we cannot build Qt due to the circular dependency
>>>>>> between
>>>>>> Qt and its build tool? This is a showstopper.
>>>>>>
>>>>>> > GN[1] is another example of build system which didn't care too much
>>>>>> > about
>>>>>> > 1.a,b,c and it still used in quite big projects (e.g. chrome,
>>>>>> > fuchsia). To
>>>>>> > my huge surprise, they managed to move it into a separate repo and
>>>>>> > remove
>>>>>> > all chromium dependencies (yep, a few months ago you had to checkout
>>>>>> > the
>>>>>> > entire chromium repo to build it :) ).
>>>>>>
>>>>>> GN (and its predecessor Gyp) is universally hated by distribution
>>>>>> packagers
>>>>>> for its non-standardness, weirdness, lack of documentation (including
>>>>>> third-
>>>>>> party documentation such as tutorials, an issue inherent to custom
>>>>>> build
>>>>>> systems) and lack of flexibility (custom build systems are never as
>>>>>> powerful
>>>>>> as widely-used general-purpose build systems).
>>>>>>
>>>>>> QtWebEngine is a particular pain to package because it uses TWO custom
>>>>>> build
>>>>>> systems (QMake and GN).
>>>>>>
>>>>>> The Chromium mess is also what prompted Spot to write the list of
>>>>>> FAILs
>>>>>> [https://spot.livejournal.com/308370.html] I have already linked to
>>>>>> elsewhere in this thread.
>>>>>>
>>>>>>
>>>>>> There is a build system that fulfills all of Thiago's points, and it
>>>>>> is
>>>>>> already widely used in the Qt community: CMake.
>>>>>>
>>>>>>         Kevin Kofler
>>>>>>
>>>>>> _______________________________________________
>>>>>> Development mailing list
>>>>>> Development at qt-project.org
>>>>>> http://lists.qt-project.org/mailman/listinfo/development
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Development mailing list
>>>>> Development at qt-project.org
>>>>> http://lists.qt-project.org/mailman/listinfo/development
>>>
>>>
>