[Development] Build system for Qt 6

[Ray Donnelly]

On Sat, Dec 15, 2018, 6:35 AM Alexander Neundorf <neundorf at kde.org wrote:

> On 2018 M10 30, Tue 18:33:03 CET NIkolai Marchenko wrote:
> > > Thus this investment would be at the expense of other things we’d like
> to
> >
> > do, like improving our IDE, working on rearchitecting and cleaning up our
> > core frameworks for Qt 6 or the design tooling we are currently investing
> > into. The Qt Company believes that those other investments are more
> > important for the future of Qt than our choice of build tool.
> >
> > I don't understand. Will it not be a return on the investment when people
> > use Qt "because their build tool is the best around" ?
> > Project files are at the root of every project. There are all sorts of
> good
> > IDEs around but ppl mostly are forced to use CMAKE which no one seems to
> > like.
>
> I do like it :-P
> CMake can generate not only Makefiles and ninja files, but also project
> files for
> IDEs (Visual Studio, XCode, Eclipse).
> With the addition of "server mode" 2 or 3 years ago or so now also a tight
> integration with IDEs is possible. I think QtCreator and/or KDevelop make
> use
> of this.
> So, when using cmake the developer is free to chose whether he wants to
> use
> simply an editor and make/ninja, or a full IDE.
>

In my experience with cmake any non trivial implementation only tends to
work with the generator(s) the developer tested against most recently. Also
even when more than one generator works on a given platform, the binaries
produced will differ in many ways, some important, some not so important.
This is a terrible situation.

Other than that to achieve this multi generator goal, you end up with a
lowest common denominator or features (or generators that cannot be used on
a given project).

I dislike meta-make systems. They work ok for software developers but for
software packagers they tend to be very problematic.

Do you know for example that cmake will find dlls in C:\Windows\System32,
common libs like zlib often get put there and disabling this requires an
explicit option to be passed (and discovering that this is what happens and
how to prevent it were far from trivial - find_package is still
inscrutable, and it's for sure the cause of most issues we see as software
packagers).


> Alex
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20181215/3bf2b8c4/attachment.html>