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

Kevin Kofler kevin.kofler at chello.at
Fri Dec 14 13:51:58 CET 2018


Christian Gagneraud wrote:
> On Fri, 14 Dec 2018 at 00:54, Kevin Kofler <kevin.kofler at chello.at> wrote:
>> I am looking forward to this bootstrapping hack going away by just using
>> CMake.
> 
> So you want to replace a bunch of scripts with another bunch of
> scripts, and magically the maintenance burden will be gone?

A CMakeLists.txt is not a handwritten bootstrapping script, but a full-
fledged replacement for a QMake .pro file. Sure, a CMakeLists.txt is a form 
of script, but so is a QMake .pro file.

My point is that you do not need to duplicate parts of the build scripts to 
a handwritten shell script just to bootstrap the build tool. (Bootstrapping 
CMake is not something Qt has to deal with, Qt can assume the binary to just 
be there. Users will typically just download an upstream or distro-packaged 
binary and not bootstrap CMake themselves.)

And of course CMake itself is not a script, but a C++ executable.

> My bet is that it will never happen, you'll still need the power of
> perl, python or javascript to do the "dirty job", CMake is not
> expressive enough, by design.

For things like custom code generators, maybe, if you cannot or do not want 
to use Qt executables for them for whatever reason (e.g., if you need the 
generated code to compile QtCore). But a wrapper script around CMake (in the 
style of the Qt configure script) should never be needed.

Also, do not understimate what CMake can do, especially with functions, 
which make it theoretically Turing-complete. (That said, you might actually 
want to restrict or ban the use of recursive (or all) functions in your 
CMakeLists.txt coding style if you want to ensure that your script will 
terminate, and do so in a reasonable time. You can have only EITHER 
decidability OR Turing-completeness, not both.)

>> > The Qt Company has been looking for "employees" to work on Qbs for
>> > month before dropping it, apparently nobody responded, or something...
>>
>> Then that would pretty much explain why they cannot maintain it in the
>> long run.
> 
> You are right, and it would be nice to have official statements on
> that. What did really happen?

That's a question I cannot answer, as I am not employed by nor otherwise 
affiliated with the Qt Company. I wonder whether those who know the answer 
(I don't) are allowed to tell you.

> It's not just the output expressions, the whole page "smells bad".
> Take '$<COMMA>' for example, it reminds me of m4, make and qmake, like
> we haven't moved away from the old daemons.

CMake feels a lot less hackish than autoconf/m4. Mainly because there is 
just one level of scripting language, whereas autoconf is a layer on top of 
m4. E.g., the escaping rules for autoconf are particularly arcane, you often 
have to escape the same expression multiple times: for autoconf, for m4, for 
the shell. CMake does not have such a legacy.

>> This is a bug that was already fixed by:
>> https://gitlab.kitware.com/cmake/cmake/merge_requests/2668
> 
> Apparently it will make it into 3.14, in 2 months.
> It's a bummer to have to maintain a work around, or should i add cmake
> to my toolkit, so that i can keep track of patches?

Technically, the simplest workaround would be to just not use Windows as the 
build host for cross compilation. :-) But I guess producing a cmake.exe with 
the patch backported or from a git snapshot as a one-off workaround, or even 
just pointing to the nightly snapshot binaries from:
https://cmake.org/files/dev/?C=M;O=D
would be the easiest workaround to put in place. The issue affects only 
Windows build hosts (not compilations on other build hosts for Windows, nor 
any other host/target combinations), so only a Windows .exe with the patch 
is needed. And it can be dropped when 3.14 is released.

> Do you foresee more problems like that?

Unfortunately, I do not have the magic crystal ball required for that. ;-)

        Kevin Kofler




More information about the Development mailing list