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.andr...@gmail.com> wrote: > On Sat, Jul 21, 2018 at 4:42 PM, Jean-Michaël Celerier > <jeanmichael.celer...@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.andr...@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.celer...@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.andr...@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.celer...@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.kof...@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@qt-project.org > >>>>>> http://lists.qt-project.org/mailman/listinfo/development > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Development mailing list > >>>>> Development@qt-project.org > >>>>> http://lists.qt-project.org/mailman/listinfo/development > >>> > >>> > > >
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
