[Development] Qt 6 buildsystem support requirements

[Ray Donnelly]

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/67927b01/attachment.html>