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

[Siddharth Heroor <heroor@ti.com>]

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@yoctoproject.org [mailto:meta-ti-
>>> bounces@yoctoproject.org] On Behalf Of Heroor, Siddharth
>>> Sent: Thursday, June 27, 2013 12:17 PM
>>> To: meta-ti@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@ti.com>
>>> Signed-off-by: Siddharth Heroor <heroor@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.

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

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