[Development] Qt 6 buildsystem support requirements
Jean-Michaël Celerier
jeanmichael.celerier at gmail.com
Sun Jul 22 12:08:17 CEST 2018
My bad, I thought that you were counting in Kloc of code, not in kilobytes.
That's in my opinion a weird metric for measuring code since indenting
with, say, 4 spaces instead of 1 tab would certainly end up giving wild
differences.
cloc cmake/Source/cmQt*
-------------------------------------------------------------------------------
Language files blank comment
code
-------------------------------------------------------------------------------
C++ 5 371 500
4362
C/C++ Header 5 126 173
740
-------------------------------------------------------------------------------
SUM: 10 497 673
5102
-------------------------------------------------------------------------------
I don't know for you, but 5kloc of modern C++ seems to be a fairly small
price to pay to parse all my .cpp automatically for moc macros (no need to
specify headers unlike qmake!), parallel execution of multiple moc /uic /
rcc instances (
https://cmake.org/cmake/help/v3.12/prop_tgt/AUTOGEN_PARALLEL.html), direct
support for multiple files with the same name (e.g. having two files with
Q_OBJECT named Settings.h in different folders won't cause a problem with
cmake, unlike qmake which puts everything in the root build folder by
default and will happilly overwrite a moc_Settings.cpp with another), etc (
https://cmake.org/cmake/help/v3.12/prop_tgt/AUTOMOC.html).
> Playing devil's advocate, please bear with me:
> Because it makes people worry that cmake-lang is too limited, and if you
need to do certain things (*), you need to resort to patch the tool itself.
But, which build system commonly used with Qt doesn't behave like this ?
qmake is cpp + qmake-lang, qbs is cpp + QML. AFAIK meson, waf, scons do not
support automatic moc'ing. At some point, some code has to be injected in
the build tool if you want to add automatic global behaviour - and I'd take
automatic global behaviour everyday over doing stuff like this:
http://mesonbuild.com/Qt5-module.html or
https://scons.org/doc/2.0.1/HTML/scons-user/a8524.html
-------
Jean-Michaël Celerier
http://www.jcelerier.name
On Sat, Jul 21, 2018 at 7:07 PM, Ray Donnelly <mingw.android at gmail.com>
wrote:
> 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/2d1de8cc84b258174b2dc0a8080f54
> 9cd9b59b32/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/20180722/335638a9/attachment.html>
More information about the Development
mailing list