qt5 toolchain

qt5 toolchain

[Ivan Sergio Borgonovo]

I've followed the instruction for wanderboard to build an image with qt5 
support for an imx28evk based board.

I had to skip several packages because they depend on opengl.

Still I've been able to bake an image that boot.

Now I was thinking to build the toolchain for qt5.

Reading here and there it seems that I should find qmake in the sysroot 
and some env variable set (after sourcing environment-setup-*)
eg.
http://lists.qt-project.org/pipermail/qbs/2013-November/000563.html

My local.conf is a stripped down version of the one proposed for the 
wonderboard to get rid of the opengl dependencies.

I did
bitbake core-image-minimal -c populate_sdk
but I couldn't find qmake in the sysroot neither the qt related 
variables set.
QT5 headers are where they should be.

I can't bitbake
- meta-toolchain-qte (depends on x11)
- meta-toolchain-qt5 (some packages depends on opengl eg. qt3d)

What is the best way to go further?

BTW is this the right place to ask this kind of questions? It seems more 
a mailing list for the fsl developers rather than fsl users.
If it is not where should I post this kind of questions and more general 
question on yocto?

thanks

-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it

Re: qt5 toolchain

[Otavio Salvador]

On Fri, Oct 9, 2015 at 5:31 PM, Ivan Sergio Borgonovo
<mail@webthatworks.it> wrote:
> I've followed the instruction for wanderboard to build an image with qt5
> support for an imx28evk based board.
>
> I had to skip several packages because they depend on opengl.
>
> Still I've been able to bake an image that boot.
>
> Now I was thinking to build the toolchain for qt5.
>
> Reading here and there it seems that I should find qmake in the sysroot and
> some env variable set (after sourcing environment-setup-*)
> eg.
> http://lists.qt-project.org/pipermail/qbs/2013-November/000563.html
>
> My local.conf is a stripped down version of the one proposed for the
> wonderboard to get rid of the opengl dependencies.
>
> I did
> bitbake core-image-minimal -c populate_sdk
> but I couldn't find qmake in the sysroot neither the qt related variables
> set.
> QT5 headers are where they should be.
>
> I can't bitbake
> - meta-toolchain-qte (depends on x11)
> - meta-toolchain-qt5 (some packages depends on opengl eg. qt3d)
>
> What is the best way to go further?
>
> BTW is this the right place to ask this kind of questions? It seems more a
> mailing list for the fsl developers rather than fsl users.
> If it is not where should I post this kind of questions and more general
> question on yocto?

It is indeed a generic question, anyway you will need to make some
bbappend files to remove the opengl related packages from the distro
and toolchain.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: qt5 toolchain

[Ivan Sergio Borgonovo]

On 13/10/2015 15:11, Otavio Salvador wrote:

>> I can't bitbake
>> - meta-toolchain-qte (depends on x11)
>> - meta-toolchain-qt5 (some packages depends on opengl eg. qt3d)

>> What is the best way to go further?

>> BTW is this the right place to ask this kind of questions? It seems more a
>> mailing list for the fsl developers rather than fsl users.
>> If it is not where should I post this kind of questions and more general
>> question on yocto?

> It is indeed a generic question, anyway you will need to make some
> bbappend files to remove the opengl related packages from the distro
> and toolchain.

I came across this thread:
https://lists.yoctoproject.org/pipermail/meta-freescale/2015-March/013126.html

so it seems it is a recurring topic even here.
mx28 doesn't seems too much loved for the reasons you explained in a 
previous email.
 From a user point of view the lack of a bit more support in different 
places to CPU that don't have opengl is increasing friction for 
newcomers quite a bit.

I'll subscribe to openembedded ML and move the topic there to see what 
would be the quality level required for a patch to
packagegroup-qt5-toolchain-target.bb
or if I should just write my own layer to _remove stuff from there.

 From my point of view disabling opengl (and other things strictly HW 
related) should be something set in the lowest layer and be passed on to 
higher software layer so to make it clearer to higher layers that they 
should take it into account ASAP and not as a "retro-fit".

qtlocation doesn't seem to depend on qt3d anymore, but it still depends 
on qtquickcontrols that up to my memory depends on opengl.

thanks

-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it

Re: qt5 toolchain

[Otavio Salvador]

On Thu, Oct 15, 2015 at 1:26 PM, Ivan Sergio Borgonovo
<mail@webthatworks.it> wrote:
> On 13/10/2015 15:11, Otavio Salvador wrote:
>
>>> I can't bitbake
>>> - meta-toolchain-qte (depends on x11)
>>> - meta-toolchain-qt5 (some packages depends on opengl eg. qt3d)
>
>
>>> What is the best way to go further?
>
>
>>> BTW is this the right place to ask this kind of questions? It seems more
>>> a
>>> mailing list for the fsl developers rather than fsl users.
>>> If it is not where should I post this kind of questions and more general
>>> question on yocto?
>
>
>> It is indeed a generic question, anyway you will need to make some
>> bbappend files to remove the opengl related packages from the distro
>> and toolchain.
>
>
> I came across this thread:
> https://lists.yoctoproject.org/pipermail/meta-freescale/2015-March/013126.html
>
> so it seems it is a recurring topic even here.
> mx28 doesn't seems too much loved for the reasons you explained in a
> previous email.
> From a user point of view the lack of a bit more support in different places
> to CPU that don't have opengl is increasing friction for newcomers quite a
> bit.
>
> I'll subscribe to openembedded ML and move the topic there to see what would
> be the quality level required for a patch to
> packagegroup-qt5-toolchain-target.bb
> or if I should just write my own layer to _remove stuff from there.
>
> From my point of view disabling opengl (and other things strictly HW
> related) should be something set in the lowest layer and be passed on to
> higher software layer so to make it clearer to higher layers that they
> should take it into account ASAP and not as a "retro-fit".
>
> qtlocation doesn't seem to depend on qt3d anymore, but it still depends on
> qtquickcontrols that up to my memory depends on opengl.

All your feedback is valuable and I agree with it. We welcome patches
to improve the support for opengl-less CPUs or you can hire someone
(us - O.S. Systems, or other software vendor) to do the work.
Personally I do my best to address as many things as my free time can
fit so I apologize for your turn-key experience not being as good as
you wished but you can help to improve it (in one way or another).

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: qt5 toolchain

[Ivan Sergio Borgonovo]

On 10/15/2015 06:48 PM, Otavio Salvador wrote:

>> I'll subscribe to openembedded ML and move the topic there to see what would
>> be the quality level required for a patch to
>> packagegroup-qt5-toolchain-target.bb
>> or if I should just write my own layer to _remove stuff from there.

>>  From my point of view disabling opengl (and other things strictly HW
>> related) should be something set in the lowest layer and be passed on to
>> higher software layer so to make it clearer to higher layers that they
>> should take it into account ASAP and not as a "retro-fit".

>> qtlocation doesn't seem to depend on qt3d anymore, but it still depends on
>> qtquickcontrols that up to my memory depends on opengl.

> All your feedback is valuable and I agree with it. We welcome patches
> to improve the support for opengl-less CPUs or you can hire someone
> (us - O.S. Systems, or other software vendor) to do the work.
> Personally I do my best to address as many things as my free time can
> fit so I apologize for your turn-key experience not being as good as
> you wished but you can help to improve it (in one way or another).

That's my free time as well, if I had to make things "just work" I'd 
build the sdk and then just ./configure and copy stuff to the image by hand.
Unfortunately I'm pretty new to qt and yocto and sooner or later things 
will have to "just work". I'm concerned that the solution I'll come up 
with will be substandard to be merged to meta-qt5, especially if I'll be 
left alone in the cold, before the time I'll have to make things "just 
work" will come and all my efforts will be lost in time like tears in 
the rain.

Still putting together the right knowledge to try to contribute a bit back.

thanks

-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it

Re: qt5 toolchain

[Otavio Salvador]

On Thu, Oct 15, 2015 at 7:03 PM, Ivan Sergio Borgonovo
<mail@webthatworks.it> wrote:
> On 10/15/2015 06:48 PM, Otavio Salvador wrote:
>
>>> I'll subscribe to openembedded ML and move the topic there to see what
>>> would
>>> be the quality level required for a patch to
>>> packagegroup-qt5-toolchain-target.bb
>>> or if I should just write my own layer to _remove stuff from there.
>
>
>>>  From my point of view disabling opengl (and other things strictly HW
>>> related) should be something set in the lowest layer and be passed on to
>>> higher software layer so to make it clearer to higher layers that they
>>> should take it into account ASAP and not as a "retro-fit".
>
>
>>> qtlocation doesn't seem to depend on qt3d anymore, but it still depends
>>> on
>>> qtquickcontrols that up to my memory depends on opengl.
>
>
>> All your feedback is valuable and I agree with it. We welcome patches
>> to improve the support for opengl-less CPUs or you can hire someone
>> (us - O.S. Systems, or other software vendor) to do the work.
>> Personally I do my best to address as many things as my free time can
>> fit so I apologize for your turn-key experience not being as good as
>> you wished but you can help to improve it (in one way or another).
>
>
> That's my free time as well, if I had to make things "just work" I'd build
> the sdk and then just ./configure and copy stuff to the image by hand.
> Unfortunately I'm pretty new to qt and yocto and sooner or later things will
> have to "just work". I'm concerned that the solution I'll come up with will
> be substandard to be merged to meta-qt5, especially if I'll be left alone in
> the cold, before the time I'll have to make things "just work" will come and
> all my efforts will be lost in time like tears in the rain.
>
> Still putting together the right knowledge to try to contribute a bit back.

The community, myself included, can review patches and provide
feedback and possible advises how to better rework the patches. For
sure.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750