[meta-freescale] [meta-fsl-arm][PATCH] qt5: add mx5 and mx6 support

[Otavio Salvador]

On Fri, May 31, 2013 at 5:06 PM, Eric Bénard <eric at eukrea.com> wrote:

> Le Fri, 31 May 2013 13:23:29 -0300,
> Otavio Salvador <otavio at ossystems.com.br> a écrit :
>
> > On Fri, May 31, 2013 at 12:35 PM, Eric Bénard <eric at eukrea.com> wrote:
> >
> > > Le Fri, 31 May 2013 12:04:11 -0300,
> > > Otavio Salvador <otavio at ossystems.com.br> a écrit :
> > >
> > > > On Fri, May 31, 2013 at 12:02 PM, Eric Bénard <eric at eukrea.com>
> wrote:
> > > >
> > > > > Le Fri, 31 May 2013 12:00:08 -0300,
> > > > > Otavio Salvador <otavio at ossystems.com.br> a écrit :
> > > > >
> > > > > > On Fri, May 31, 2013 at 11:15 AM, Eric Bénard <eric at eukrea.com>
> > > wrote:
> > > > > >
> > > > > > > Le Fri, 31 May 2013 10:18:44 -0300,
> > > > > > > Otavio Salvador <otavio at ossystems.com.br> a écrit :
> > > > > > >
> > > > > > > > On Wed, May 29, 2013 at 3:04 PM, Eric Bénard <
> eric at eukrea.com>
> > > > > wrote:
> > > > > > > >
> > > > > > > > > - this allow to build qt5 with OpenGL ES support for i.MX5
> and
> > > > > i.MX6
> > > > > > > > > - tested on i.MX51, i.MX53 and i.MX6Q
> > > > > > > > >
> > > > > > > > > Signed-off-by: Eric Bénard <eric at eukrea.com>
> > > > > > > > >
> > > > > > > >
> > > > > > > > ...
> > > > > > > >
> > > > > > > >
> > > > > > > > >  recipes-qt/qt5/qtbase/mx5/qeglfshooks_imx5.cpp |  105
> > > > > > > > > ++++++++++++++++++++++++
> > > > > > > > >  recipes-qt/qt5/qtbase_5.0.2.bbappend           |   68
> > > > > +++++++++++++++
> > > > > > > > >
> > > > > > > >
> > > > > > > > ...
> > > > > > > >
> > > > > > > > Thinking more about it, I think we should put these inside a
> > > meta-qt5
> > > > > > > > directory so we know what will be 'included'. Otherwse we may
> > > need to
> > > > > > > pick
> > > > > > > > every file depending on each layer and it might be difficult
> to
> > > > > > > understand
> > > > > > > > what is in use and what is not.
> > > > > > > >
> > > > > > > please apply as is and create a patch on top of it to achieve
> the
> > > > > > > organization you prefer.
> > > > > > >
> > > > > >
> > > > > > No reason to apply one patch which we know that needs rework.
> > > > > >
> > > > > > Do you agree with my argument?
> > > > > >
> > > > > no ;-)
> > > > >
> > > >
> > > > Well; it would be easier if you could explain why. Do you mind to
> > > elaborate
> > > > it a little more?
> > > >
> > > if the argument is "No reason to apply one patch which we know that
> > > needs rework" :
> > > Changing the organization of the bbappend is not just a mater of
> editing
> > > the patch in a few minutes, it also means testing with and without
> > > meta-qt5 and that's very long (and I already did that for v1 when we
> > > discussed that initially).
> > > 2 days ago you told me that the RFC was fine, now you tell me that
> > > needs rework and as I don't have immediate time to rework it so if you
> > > want to change the organization or use Chris' way to add layers (which
> > > is very elegant) either create a patch to rework this one or rework the
> > > patch before applying or drop it for the moment and I may work again
> > > on that later (and in that case, please reply with the organization
> > > you want so that the work is done only one time).
> > >
> >
> > I asked you to send it as proper patch for review. I didn't noticed you
> > have put the bbappend in same level as the other so when I noticed it I
> > commented.
>
> Otavio sometimes you push the pedantry very far : the difference between
> the initial patch and what you call the "proper patch" is that the
> "proper patch" doesn't have 3 letters (RFC) in the subject and now I
> understand that having "RFC" in the subject means you didn't review the
> patch.
>

Usually RFC patches are to discuss the concept not to receive a complete
review. We did discuss it and it even allowed Chris to comment on it with a
better way of solving the problem - which is what it is the real goal of it
I think.

I didn't try the patch (I was under high volume of tests here for GPU
patches) and once I managed to get it done I started to check for backlog
in the mailing list (today) so I did look at it more carefully and found a
issue which I didn't see at first look - which I also think is normal - as
I can also make mistakes - so I don't think I was pedant but instead a
careful maintainer.

> > if the argument is "it might be difficult to understand what is in use
> > > and what is not" :
> > > as soon as you have automatic addition of sublayers you fall in a case
> > > where it's not easy to understand what is in use or not whatever is
> > > your directory organization.
> > >
> >
> > I'd put it as:
> >
> > recipes-...
> > meta-qt5/recipes-qt/qt5/...
> >
> > Or as Chris suggested:
> >
> > recipes-...
> > qt5-layer/recipes-qt/qt5
> >
> > Both ways looks good for me.
> >
> please choose ONE way so that the next patch iteration get THE right
> one for you.


Let's go with Chris proposal than; it avoids future rework in bblayers.conf
I think.

So the way I see it, it could be done as:

* one patch adding the bblayers.conf change
* one for Qt5 additions

Regards,

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-freescale/attachments/20130531/b1d09bfe/attachment.html>