[meta-ti] [PATCH] libdrm: Add GLSDK specific staging tree for omap-a15

[Siddharth Heroor]

On 6/28/2013 2:46 PM, Siddharth Heroor wrote:
> On 6/28/2013 12:47 AM, Denys Dmytriyenko wrote:
>> On Thu, Jun 27, 2013 at 05:46:43PM +0000, Maupin, Chase wrote:
>>>> -----Original Message-----
>>>> From: meta-ti-bounces at yoctoproject.org [mailto:meta-ti-
>>>> bounces at yoctoproject.org] On Behalf Of Heroor, Siddharth
>>>> Sent: Thursday, June 27, 2013 12:17 PM
>>>> To: meta-ti at yoctoproject.org
>>>> Subject: [meta-ti] [PATCH] libdrm: Add GLSDK specific staging tree
>>>> for omap-a15
>>>>
>>>> * Override SRC_URI to use TI's tree at
>>>> https://git.ti.com/glsdk/libdrm
>>>>  This tree includes patches on top of the upstream libdrm for
>>>>  omap5 and dra7xx class of devices.
>>>>
>>>> Signed-off-by: Mrinmayee Hingolikar <mrinmayee at ti.com>
>>>> Signed-off-by: Siddharth Heroor <heroor at ti.com>
>>>> ---
>>>> recipes-graphics/drm/libdrm_2.4.41.bb |   15 +++++++++++++++
>>>> 1 files changed, 15 insertions(+), 0 deletions(-)
>>>> create mode 100644 recipes-graphics/drm/libdrm_2.4.41.bb
>>>>
>>>> diff --git a/recipes-graphics/drm/libdrm_2.4.41.bb b/recipes-
>>>> graphics/drm/libdrm_2.4.41.bb
>>>> new file mode 100644
>>>> index 0000000..31f7cee
>>>> --- /dev/null
>>>> +++ b/recipes-graphics/drm/libdrm_2.4.41.bb
>>>
>>> I thought you were going to bbappend this instead of overlaying the whole 
>>> recipe.
>>
>> I was confused at first as well, but I guess it should be fine, considering 
>> there's no 2.4.41 version to bbapend anyway.
> 
> Sorry about that. The original code we were working on was a .bbappend
> to override recipes-graphics/drm/libdrm_git. However, the latest version
> in oe-core on danny is 2.4.39 and master is 2.4.45. I chose to use
> libdrm_2.4.41.bb because that's easier to read for me :-)
> 
>>
>>
>>>> @@ -0,0 +1,15 @@
>>>> +require recipes-graphics/drm/libdrm.inc
>>>> +
>>>> +COMPATIBLE_MACHINE = "omap-a15"
>>>> +
>>>> +DEFAULT_PREFERENCE = "-1"
>>>> +
>>>> +EXTRA_OECONF += "--enable-omap-experimental-api"
>>>> +
>>>> +SRC_URI = "git://git.ti.com/glsdk/libdrm.git;protocol=git"
>>>> +SRCREV = "3cb5405084111193cedb8796d259b56560b088f0"
>>>> +
>>>> +# Append to the PR so that a new SRCREV will cause a rebuild
>>>> +PR_append = "a+gitr${SRCPV}"
>>>
>>> I always had issue with this.  I'm not sure that this statement holds true 
>>> because whether a new SRCREV will cause a rebuild would depend on whether 
>>> that SRCREV sorts higher than the old one.  Unless something else has 
>>> changed.  This is useful though if you want to know what SRCREV was used for 
>>> a build.
>>
>> Well, if every time you update SRCREV you also increment the first letter, it 
>> will work as expected - so the comment is kind of correct... :)
>>
> 
> Right, I just followed the existing kernel recipes for convention. Would
> the convention change between a kernel recipe (like
> recipes-kernel/linux/linux-ti-staging_3.8.bb) where we have both SRCPV
> and the first letter, compared to userspace recipes which point to git
> trees for versions?
> 
> 
>>
>>> That being said if you were going to overlay this recipe the PR should be 
>>> something like
>>>
>>> PR = "${INC_PR}.0"
>>>
>>> Right now you are appending to the default since PR is not defined.  With a 
>>> bbappend you should append a -arago flag.
>>>
>>> So this comes back to why no bbappend?  Is it because the base version in 
>>> oe-core is 2.4.39 and not 2.4.41?  Can you not append the _git version of 
>>> the recipe and update the PV appropriately?
>>>
> 
> That's also possible but the question I have is what's the preferred
> convention?
> 
> All the GLSDK trees are on git. The choice really is between having a
> since .bbappend for each of the trees with an explicit PV and bump the
> PV everytime we update to latest on upstream *OR* have a recipe for the
> version and submit a new recipe when we update to latest.

Sorry. My typing went haywire...

What I mean is I can resubmit _git.bbappend. Its really whatever
convention you would suggest we follow. All the recipes that we have are
on git (except for a couple of binary blobs).

Do you think we should use _git.bbappend (or _git.bb as the case maybe)?
In that case, we only 1 recipe to maintain per software package and we
fix the PV in it.

> 
> I can submit a v2 once I understand the expected convention to be followed.
> 

Let me know the approach to take, I'll submit new patches if required.

>>>> +
>>>> +S = "${WORKDIR}/git"
>>>> --
>>>> 1.7.0.4
>>>>
>>>> _______________________________________________
>>>> meta-ti mailing list
>>>> meta-ti at yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/meta-ti
>>> _______________________________________________
>>> meta-ti mailing list
>>> meta-ti at yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/meta-ti
>