Re: Building auxiliary tools in qmake2-native

[Michael Krelin <hacker@klever.net>]

> 
> Will the opie-lrelease-native work? If not, a lrelease-native package
> sounds like the way to go.

I'd guess opie-lrelease-native is a bit outdated for qt4, but I've never 
used it, so I'm not sure.

>>>> The other thing is that when building uicmoc with qt3support module OE
>>>> has to build almost the whole qt, anyway. Would it not be better if we
>>>> just have qt-native package with all the tools installed? That would
>>>> reduce the amount of merciless and senseless patching and I believe
>>>> would reduce the slice of disk-space/cpu-time continuum eaten up by most
>>>> of the builds.
>>> I'm pretty much agnostic about the breakdown of the particular
>>> packages that end up providing the native tools used during target
>>> builds.
>> I understand, this pretty general question was a call for opinions.
> 
> The general idea is OE should build its own tools where its feasible to
> do so. Since most of the QT tools already exist, it sounds like we just
> need to add a missing one.
> 
> Note that anyone wanting to shortcut the builds can do so by setting the
> ASSUME_PROVIDED variable to contain the native packages they don't wish
> to build.

That wasn't a question of whether we should use build system's qt tools, 
it was about not splitting qt into many native packages, but rather 
using a single qt-native, since, for instance, qmake2-native has to 
build half a qt, anyway, to support qt3 compatibility layer. I don't 
think dropping qt3support is a feasible option. If not, then, of course 
adding a missing lrelease-native is the way to go.

Love,
H