[OE-core] [PATCH] classes: add gitupstream class

[Andre McCurdy]

On Wed, Mar 8, 2017 at 12:54 PM, Andre McCurdy <armccurdy at gmail.com> wrote:
> On Wed, Mar 8, 2017 at 9:25 AM, Ross Burton <ross.burton at intel.com> wrote:
>> This class lets you use BBCLASSEXTEND to add a variant of the recipe that
>> fetches from git instead of a tarball.
>
> Looks good. This approach could perhaps also cover git -vs-
> externalsrc variants of a recipe, which seems to be a big topic for a
> lot of users.
>
>> For example:
>>
>>  BBCLASSEXTEND = "gitupstream:target"
>>  SRC_URI_class-gitupstream = "git://git.example.com/example"
>>  SRCREV_class-gitupstream = "abcd1234"
>>
>> This variant will have DEFAULT_PREFERENCE set to -1 so it needs to be selected
>> to be used
>
> So if I want to select the gitupstream variant, what should I set
> PREFERRED_VERSION to?
>
>>, and any git-specific tweaks can be done with the class-gitupstream
>> override, for example:
>>
>>  DEPENDS_append_class-gitupstream = " gperf-native"
>>
>>  do_configure_prepend_class-gitupstream() {
>>     touch ${S}/README
>>  }
>>
>> It currently only supports creating a git variant of the target recipe, not
>> native or nativesdk.  The BBCLASSEXTEND syntax (gitupstream:target) was chosen
>> so that support for native and nativesdk can be added at a later date.
>>
>> [ YOCTO #10215 ]
>>
>> Signed-off-by: Ross Burton <ross.burton at intel.com>
>> ---
>>  meta/classes/gitupstream.bbclass | 25 +++++++++++++++++++++++++
>>  1 file changed, 25 insertions(+)
>>  create mode 100644 meta/classes/gitupstream.bbclass
>>
>> diff --git a/meta/classes/gitupstream.bbclass b/meta/classes/gitupstream.bbclass
>> new file mode 100644
>> index 0000000..405283d
>> --- /dev/null
>> +++ b/meta/classes/gitupstream.bbclass
>> @@ -0,0 +1,25 @@
>> +CLASSOVERRIDE = "class-gitupstream"
>> +
>> +# TODO doesn't let you gitupstream a native recipe yet
>> +
>> +python gitupstream_virtclass_handler () {
>> +    # Do nothing if this is inherited, as it's for BBCLASSEXTEND
>> +    if "gitupstream" not in (e.data.getVar('BBCLASSEXTEND', True) or ""):
>
> What's the significance of e.data.getVar() here -vs- d.getVar() below?

To answer my own question, this seems to be covered in the bitbake user manual:

"The global datastore is available as "d". In legacy code, you might
see "e.data" used to get the datastore. However, realize that "e.data"
is deprecated and you should use "d" going forward."

http://www.yoctoproject.org/docs/2.2.1/bitbake-user-manual/bitbake-user-manual.html#events

> (I ask because I've tried writing a few RecipePreFinalise event
> handlers and they don't always work quite as expected, so maybe I've
> been getting this wrong...).
>
>> +        bb.error("Don't inherit gitupstream, use BBCLASSEXTEND")
>> +        return
>> +
>> +    variant = d.getVar("BBEXTENDVARIANT", True)
>
> Maybe drop the ", True" ?
>
>> +    if variant not in ("target"):
>> +        bb.error("Pass the variant when using gitupstream, for example gitupstream:target")
>> +
>> +    d.setVar("DEFAULT_PREFERENCE", "-1")
>> +    d.setVar("S", "${WORKDIR}/git")
>> +
>> +    # Modify the SRCREV, if the recipe hasn't used PV_class-gitupstream to
>> +    # assign a +gitX PV already.
>> +    pv = d.getVar("PV", True)
>> +    if "+git" not in pv:
>> +        d.setVar("PV", pv + "+git${SRCPV}")
>> +}
>> +addhandler gitupstream_virtclass_handler
>> +gitupstream_virtclass_handler[eventmask] = "bb.event.RecipePreFinalise"
>> --
>> 2.8.1
>>
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core at lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core