Building auxiliary tools in qmake2-native

Building auxiliary tools in qmake2-native

[Matt Hoosier]

Hi all,

I've a Qtopia application whose build needs to use some of the i18n
tools available from the Qt source distribution. I suppose that
qmake2-native would be the likely package to supply those, in the
current state it doesn't. Presumably, this is because Trolltech's
configure script forces these to be disabled on a cross-compilation.

My naive attempt to do this by patching the configure script not to
forcibly remove the 'tools' from cross-builds ended badly; several
headers presumably generated by native tools were missing. Does the
maintainer of the Qt tools and build have an opinion on whether
there's a better way to get some of the auxiliary tools built?

The specific one I'm seeking is 'lrelease'.

--Matt

Re: Building auxiliary tools in qmake2-native

[Michael Krelin]

I'm not a qt expert and even less qtopia expert, but I happened to do a 
bit of work on qt in OE. That was both an excuse for my ignorance and 
the explanation of why the hell I find it appropriate to chime in all.

I do not know what 'lrelease' is (ignorant, remember?), so I'd also ask 
if you really sure that, for instance, uicmoc is not a better place for 
the tool than qmake?

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.

Does anyone happen to have an opinion?

Love,
H


> I've a Qtopia application whose build needs to use some of the i18n
> tools available from the Qt source distribution. I suppose that
> qmake2-native would be the likely package to supply those, in the
> current state it doesn't. Presumably, this is because Trolltech's
> configure script forces these to be disabled on a cross-compilation.
> 
> My naive attempt to do this by patching the configure script not to
> forcibly remove the 'tools' from cross-builds ended badly; several
> headers presumably generated by native tools were missing. Does the
> maintainer of the Qt tools and build have an opinion on whether
> there's a better way to get some of the auxiliary tools built?
> 
> The specific one I'm seeking is 'lrelease'.
> 
> --Matt
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: Building auxiliary tools in qmake2-native

[Matt Hoosier]

Hi Michael,

On 7/17/07, Michael Krelin <hacker@klever.net> wrote:
> I'm not a qt expert and even less qtopia expert, but I happened to do a
> bit of work on qt in OE. That was both an excuse for my ignorance and
> the explanation of why the hell I find it appropriate to chime in all.
>
> I do not know what 'lrelease' is (ignorant, remember?), so I'd also ask
> if you really sure that, for instance, uicmoc is not a better place for
> the tool than qmake?
>

This is the tool which generates the final binary version of the
message catalogs. The equivalent for a libintl-based project would be
"msgfmt."

I had completely managed to overlook the presence of the uicmoc-native
packages. Let me give those a try before bothering anybody further
about this stuff.

> 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.

Thanks

Re: Building auxiliary tools in qmake2-native

[Michael Krelin]

>> I do not know what 'lrelease' is (ignorant, remember?), so I'd also ask
>> if you really sure that, for instance, uicmoc is not a better place for
>> the tool than qmake?
>>
> 
> This is the tool which generates the final binary version of the
> message catalogs. The equivalent for a libintl-based project would be
> "msgfmt."

Thanks, that explains the purpose of the tool, but I would be still in 
doubt where should it go if not in lrelease-native (after all we do have 
opie-lrelease-native package).

> I had completely managed to overlook the presence of the uicmoc-native
> packages. Let me give those a try before bothering anybody further
> about this stuff.

No, I think I know it's not there.

>> 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.

Love,
H

Re: Building auxiliary tools in qmake2-native

[Matt Hoosier]

On 7/18/07, Michael Krelin <hacker@klever.net> wrote:
> I understand, this pretty general question was a call for opinions.
>

Is there any opinion formed about this yet?

Re: Building auxiliary tools in qmake2-native

[Richard Purdie]

On Wed, 2007-07-18 at 00:06 +0200, Michael Krelin wrote:
> >> I do not know what 'lrelease' is (ignorant, remember?), so I'd also ask
> >> if you really sure that, for instance, uicmoc is not a better place for
> >> the tool than qmake?
> >>
> > 
> > This is the tool which generates the final binary version of the
> > message catalogs. The equivalent for a libintl-based project would be
> > "msgfmt."
> 
> Thanks, that explains the purpose of the tool, but I would be still in 
> doubt where should it go if not in lrelease-native (after all we do have 
> opie-lrelease-native package).

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

> >> 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.

Cheers,

Richard

Re: Building auxiliary tools in qmake2-native

[Michael Krelin]

> 
> 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

Re: Building auxiliary tools in qmake2-native

[Lorn Potter]

Michael Krelin wrote:
>> 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.

Yes, lrelease is version specific.


> 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.


If you configure with qt3-support in qt4, I think you won't get all of 
Qt 4's features, but I could be wrong, or it might have changed.



-- 
Lorn 'ljp' Potter
Software Engineer, Systems Group, MES, Trolltech