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

Andre McCurdy armccurdy at gmail.com
Wed Mar 8 20:54:04 UTC 2017


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?

(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



More information about the Openembedded-core mailing list