[Development] Qt 6 buildsystem support requirements

Jean-Michaël Celerier jeanmichael.celerier at gmail.com
Sat Jul 21 17:42:37 CEST 2018


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).

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
>>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20180721/21090d1f/attachment.html>


More information about the Development mailing list