[Development] One qmake and cross compilation for different targets

[Oswald Buddenhagen]

On Fri, Aug 23, 2013 at 11:40:55AM +0200, Tomasz Olszak wrote:
> 2013/8/23 Oswald Buddenhagen <oswald.buddenhagen at digia.com>
> > the blackberries asked me the same question a few days ago ...
> >
> If it was on ML, I didn't spot it then - sorry.
> 
it was private, otherwise my whole reply would have been a link.
it was merely meant to illustrate that this is a common problem.

> I don't know if I put things clearly. I don't know qmake. moc, rcc
> internals but I do know that they are tightly dependent on Qt version. How
> hard could it be to:
> 1. Prepare some metadata+mksecs with Qt targets binaries maybe in some dev
> tools package. (maybe this metadata is only qtbase/configure internal args,
> output of tests and so on)
> 2. prepare qmake, moc, rcc source packages.
> 3. Build host dev tools for crosscompilation from these src qmake, moc and
> rcc packages and metadata. I would like to pass only hostrefix,
> crosscompiler and sysroot path for configure. Rest info will be taken from
> mentioned metadata. This process can be automated with QtCreator plugin.
> 
> Is it possible? If yes how hard is that?
>
to summarize: ?!?!?
if you want hacks, just follow the instructions i gave you.

but what you really want is dropping the host tool build from the
x-build and using a pre-built host build of qt instead. that is easy to
build into configure, but hard to make useful, because the tools were
never designed to work with a "foreign" qt build. e.g., lupdate and
lrelease call the qmake in their own binary dir to find out about
"their" qt build, and of course qmake is bound to the build. within the
build, configure-generated files are freely mixed with static files
(both c++ headers and qmake pri files). it's a total mess.
i'm planning to untangle this *somehow* for 5.3 (hopefully), but don't
expect any related activity before that.