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 < [email protected]> 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 <[email protected]> > 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 < >> [email protected]> 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 <[email protected]> >>> 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 >>>> [email protected] >>>> http://lists.qt-project.org/mailman/listinfo/development >>>> >>> >>> _______________________________________________ >>> Development mailing list >>> [email protected] >>> http://lists.qt-project.org/mailman/listinfo/development >>> >> >
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
