[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