[Development] CMake && QtCreator cross-compilation for ARM fails

[Adam Treat]

FWIW, Denis: I feel your pain and agree that the Qt Company and Qt Project have a responsibility to make cross compilation with CMake just work out of the box when you have the necessary kits installed in QtCreator.

There is absolutley no excuse for us not doing this. We as a company should be very careful to make this work as developers who *use* Qt won’t care at all if CMake causes them to lose time resetting up their tool chains for cross compilation.

I have also noticed that CMake does not work out of the box with many of our Boot2Qt kits. Needs fixing ASAP.


________________________________
From: Development <development-bounces at qt-project.org> on behalf of Denis Shienkov <denis.shienkov at gmail.com>
Sent: Thursday, December 13, 2018 4:59 AM
To: chgans at gmail.com
Cc: development at qt-project.org; kevin.kofler at chello.at
Subject: Re: [Development] CMake && QtCreator cross-compilation for ARM fails

> And it would be much worse for QBS, which requires much more from Qt than
> QMake. It requires QML, JavaScript, etc.

So what? A GCC too compiles with GCC... For me, as a developer it is not a
big problem and not a my. A worse problem is in CMake's ideology.

QBS just work immediatelly! Unlike of CMake! And a fact that the QBS's
just work cover all CMake's bootstrap crap. CMake has no one agvantage for developers!



чт, 13 дек. 2018 г. в 15:02, Denis Shienkov <denis.shienkov at gmail.com<mailto:denis.shienkov at gmail.com>>:
> Once you have the cross toolchain configured properly, which is a one-time
> setup effort, CMake will just work, too.

Will just work? What??! HAHA. Are you kidding?

Why I need to configure something? Why I need to create an additional
CMake's scripts, config files, toolchains and etc?

I already have added all required cross-compilation stuff (toolchain && rootfs) to
QtCreator. With QBS && QMake it works immediatelly! But for CMake I need in
additional unknown things.

And is it user friendly?

The Qt's PR peoples (especially the CMake maintainers) are praised that they
have added a lot of CMake && QtCreator integration improvements. But, I don't
see any results related event to a simple cross-compilation issues! It is nonsense!

How much the users need to wait for improvements for this (and other) issues with
CMake? It completelly gets stuck for a working process.

Where is CMake advantages? I see only regressions! And it is reality!

чт, 13 дек. 2018 г. в 13:48, Christian Gagneraud <chgans at gmail.com<mailto:chgans at gmail.com>>:
On Thu, 13 Dec 2018 at 12:27, Kevin Kofler <kevin.kofler at chello.at<mailto:kevin.kofler at chello.at>> wrote:
Hi Kevin,
> > PS: WTF? Why the Qt's management choosed the CMake's instead of QBS?
>
> Because CMake is a widespread tool written in C++/STL

Some people are scared of the wolf, i'm scared of the sheepple.

> (so, unlike QBS, it
> does not depend on Qt, which would mean a circular dependency when building
> Qt),

qmake has this problem, yet it's been packaged for 10+ years without a problem.

> widely packaged for GNU/Linux distributions, and with binaries for
> Windows and macOS shipped by CMake upstream (Kitware) themselves. It has a
> live upstream at Kitware, so Qt does not have to maintain it. And it is
> already widely used in the Qt and KDE community.

What a bunch of cheap free statements, w/o proper comparison.

>
> QBS, on the other hand, is a custom tool, in practice only used by Qt and a
> few Qt-using projects (I know the aim is to support also non-Qt projects,
> but this is not really used in the wild), which requires constant
> maintenance effort from the Qt project.

Can you point me to something that shows the Qt "project" contributing
to the Qt "company" on that very particular topic?
The Qt Company has been looking for "employees" to work on Qbs for
month before dropping it, apparently nobody responded, or something...

> >  From my point of view, the CMake it is a crap...
>
> CMake is not a "crap", it is a powerful tool, almost as easy to use as
> QMake, but a lot more flexible and powerful.

Cmake is crap, it is a macro based language, like it's good to be back
in the 80's.
It has no semantic, and no concept apart form 'macro', the syntax
sucks, big time, every thing is just 'expression', read that one:
https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html#output-expressions
And read that again and again, until you brain says: 'Actually, CMake
is "crap"!'

>
> > I know, that I'm not a CMake expert, but Why I need to spent a lot time
> > to make the CMake working wich an unknown result,
> > instead of just using QBS? Cross-compilation with QBS works
> > immediatelly, but with CMake sucks!
>
> Once you have the cross toolchain configured properly, which is a one-time
> setup effort, CMake will just work, too.

Oh yeah! Unless you hit some bugs, like, CMake-based cross-compilation
doesn't actually exists (yet) on Windows:
https://github.com/Kitware/CMake/commit/5f0f84c7e0630d7b8190c18badd5a68e2dd08ff7

I'm telling you: with CMake, it's 1988 Christmas, right now!

Chris.
_______________________________________________
Development mailing list
Development at qt-project.org<mailto: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/e368afe8/attachment.html>