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

Thiago Macieira thiago.macieira at intel.com
Fri Dec 14 16:13:01 CET 2018


On Friday, 14 December 2018 04:51:58 PST Kevin Kofler wrote:
> > 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.

We've been very careful not to require Perl or Python to build Qt from release 
tarballs, at least qtbase. I think we do have one use of Perl (the ELF version 
files), but it's restricted to ELF systems (Linux, FreeBSD, etc.) and its 
input could conceivably be generated by syncqt prior to packaging.

Other things are executables. Take a look at the qfloat16-tables application, 
which is C++ but all it does is generate a couple of tables that will not EVER 
change.

If the restriction were lifted, we'd probably stop committing pre-generated 
sources to the repository:
 * the QXmlStreamReader parser (generated by qlalr)
 * the Unicode tables (generated by a Python script)
 * the QLocale tables (generated by a Python script)

There are also a couple of string tables that can probably be replaced by 
C++11 constexpr code. We just have to be careful: the XCB key table was 
replaced in 5.12 and caused some Clang build to fail because it has too deep 
template recursion.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center






More information about the Development mailing list