On cross-compiling qml extensions, qt packaging needs changing

[Scott Kitterman]

On Wednesday, September 04, 2013 11:34:55 Scott Kitterman wrote:
> Dmitrijs Ledkovs <dmitrij.ledkov at ubuntu.com> wrote:
> >On 4 September 2013 12:09, Scott Kitterman <ubuntu at kitterman.com>
> >
> >wrote:
> >> Dmitrijs Ledkovs <dmitrij.ledkov at ubuntu.com> wrote:
> >> Changes like this should really be coordinated in Debian so we don't
> >
> >accumulate long term differences that can't easily be resolved.
> >
> >
> >Yeah, and as far as I know Timo is doing excellent work at keeping
> >packaging in sync as much as possible.
> >But e.g. w.r.t. multiarch & cross-compilation overall at the moment
> >Debian is still far behind Ubuntu, despite myself and many others
> >pushing many mutli-arch changes back to debian.
> 
> He is. For changes that can't be pushed to Debian now (I guess such as
> this), there should still be up front coordination on the approach so
> Ubuntu doesn't head off in one direction and discover later that it's
> unacceptable in Debian and then Ubuntu is stuck with a permanent diff or a
> lot of rework.
> 
> If such coordination has been done, I haven't seen it on what I would
> imagine to be the relevant lists.
> >> Why do you need to cross compile QML anyway? It's not like you need
> >
> >it for bootstrapping.
> >
> >
> >This is not to cross compile QML itself. This is for 3rd party
> >developers to cross-compile their compiled qml extensions against
> >ubuntu's armhf qt to be included as part of their applications for
> >Ubuntu Touch.
> >Or e.g. to cross-compile ubuntu-touch-settings or other packages we
> >have in the archive that have qml extensions.
> >Going via this route though (make qmake support cross-compilation with
> >a debian specific toolchain file), will eventually make possible to
> >cross-compile qt itself and also be upstream able patches for qmake.
> 
> It sounds at least vaguely reasonable. My main concern is that the
> coordination is done.

OK, so I checked.  No, no coordination had been done and the response I got 
was that this should be accommodated upstream rather than in the packaging.  I 
think that's reasonable.  Before this is done in Ubuntu, there should be some 
discussion with upstream about a long term plan for supporting this use case.  
I know an upstream fix won't be available for saucy and likely not even for 
"T", but the path to an upstream resolution should be started before we start 
on a divergence like this.

Scott K