Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: mikko.rapeli@linaro.org, openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] u-boot: set git repo branch with SRCBRANCH
Date: Tue, 08 Apr 2025 10:00:05 +0100	[thread overview]
Message-ID: <e20b2f4791b7481a018ce2c5d3cee9ede1a88fe9.camel@linuxfoundation.org> (raw)
In-Reply-To: <20250404075136.385270-1-mikko.rapeli@linaro.org>

On Fri, 2025-04-04 at 10:51 +0300, Mikko Rapeli via lists.openembedded.org wrote:
> Enables changing branch from "master" to "next"
> when building bleeding edge upstream versions for
> testing purposes. Now local.conf setup to
> build latest "next" version becomes:
> 
> INHERIT += "poky-bleeding"
> POKY_AUTOREV_RECIPES += "u-boot"
> SRCBRANCH:pn-u-boot = "next"
> 
> Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> ---
>  meta/recipes-bsp/u-boot/u-boot-common.inc | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/recipes-bsp/u-boot/u-boot-common.inc b/meta/recipes-bsp/u-boot/u-boot-common.inc
> index fc860248ed..9e96c46b74 100644
> --- a/meta/recipes-bsp/u-boot/u-boot-common.inc
> +++ b/meta/recipes-bsp/u-boot/u-boot-common.inc
> @@ -13,8 +13,8 @@ PE = "1"
>  # We use the revision in order to avoid having to fetch it from the
>  # repo during parse
>  SRCREV = "6d41f0a39d6423c8e57e92ebbe9f8c0333a63f72"
> -
> -SRC_URI = "git://source.denx.de/u-boot/u-boot.git;protocol=https;branch=master"
> +SRCBRANCH ?= "master"
> +SRC_URI = "git://source.denx.de/u-boot/u-boot.git;protocol=https;branch=${SRCBRANCH}"
>  
>  S = "${WORKDIR}/git"
>  B = "${WORKDIR}/build"

I do want to be able to do this kind of thing, so to be clear, I do
strongly support the idea.

I am however worried about the implication of how this will scale (or
not). If I merge this, I'm likely to get this change for many other
recipes. I also suspect people will want to parameterise the
"source.denx.de/u-boot/u-boot.git" url part too so they can use their
own local repo.

I can't help wonder if we need some other mechanism for this. I've
talked with Joshua about variable "filter" mecahnisms before which
would be one idea. It would also be possible to filter the variable
with some inline python magic, in much the same way that the code
already tweaks SRCREV to add AUTOREV.

I did also wonder whether our mirror rewriting code could be used
somehow...

Cheers,

Richard






  parent reply	other threads:[~2025-04-08  9:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-04  7:51 [PATCH] u-boot: set git repo branch with SRCBRANCH Mikko Rapeli
2025-04-07 17:05 ` [OE-core] " Alexander Kanavin
2025-04-08  6:42   ` Mikko Rapeli
2025-04-08  7:51     ` Alexander Kanavin
2025-04-08  9:00 ` Richard Purdie [this message]
2025-04-08 10:40   ` Mikko Rapeli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e20b2f4791b7481a018ce2c5d3cee9ede1a88fe9.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=mikko.rapeli@linaro.org \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox