Re: [yocto] Modifying SRC_URI before it is parsed by the fetcher
EXT-Antti Gärding <[email protected]> Wed, 13 May 2026 14:22:31 +0000
| Newsgroups | org.yoctoproject.lists.yocto |
|---|---|
| Message-ID | <AS8PR08MB7251A410724D0D006312018ED5062@AS8PR08MB7251.eurprd08.prod.outlook.com> |
--_000_AS8PR08MB7251A410724D0D006312018ED5062AS8PR08MB7251eurp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
> You still aren't saying what the condition for adding, or not adding
the tag is. What are the two scenarios here, why would one or the
other be selected? Please: if you want help, you should be forward and
clear with the use case, even if you have to disclose 'something'
about your development process.
If there is only one repository in SRC_URI, then that is the one to add the=
tag to. If there are more than one of them, then one of them is the main o=
r root repository and other repositories are cloned into subdirectories of =
that one. That one is identified based on a name parameter with help of the=
variable defined in the recipe that I mentioned earlier. Each SRC_URI entr=
y is checked to see if the tag should be added to that entry and if yes, it=
is added. If it for some reason ends up being added to several entries or =
to none, that will either cause the build to fail or the tag-commit-hash-ma=
tching in bitbake to give false positive which are both acceptable outcomes=
in that situation.
> You can probably just always inherit the class, but the class would
add the tag (or not), depending on whether some variable is set. And
then you either set it or not in your build/conf/local.conf, or some
other place that affects bitbake configuration for the build.
For debugging purposes, the appending must be easy to toggle on and off for=
any single recipe. I would accomplish that by having it packed into a clas=
s which would make its decisions based on the meta data that is already in =
the recipe inheriting it.
BR,
Antti G=E4rding
--_000_AS8PR08MB7251A410724D0D006312018ED5062AS8PR08MB7251eurp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo=
ttom:0;} </style>
</head>
<body dir=3D"ltr">
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c=
olor: rgb(0, 0, 0);">
> You still aren't saying what the condition for adding, or not adding<b=
r>
the tag is. What are the two scenarios here, why would one or the<br>
other be selected? Please: if you want help, you should be forward and<br>
clear with the use case, even if you have to disclose 'something'<br>
about your development process.<br>
</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c=
olor: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c=
olor: rgb(0, 0, 0);">
If there is only one repository in SRC_URI, then that is the one to add the=
tag to. If there are more than one of them, then one of them is the main o=
r root repository and other repositories are cloned into subdirectories of =
that one. That one is identified
based on a name parameter with help of the variable defined in the recipe =
that I mentioned earlier. Each SRC_URI entry is checked to see if the tag s=
hould be added to that entry and if yes, it is added. If it for some reason=
ends up being added to several
entries or to none, that will either cause the build to fail or the tag-co=
mmit-hash-matching in bitbake to give false positive which are both accepta=
ble outcomes in that situation.</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c=
olor: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c=
olor: rgb(0, 0, 0);">
> You can probably just always inherit the class, but the class would<br=
>
add the tag (or not), depending on whether some variable is set. And<br>
then you either set it or not in your build/conf/local.conf, or some<br>
other place that affects bitbake configuration for the build.<br>
</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c=
olor: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c=
olor: rgb(0, 0, 0);">
For debugging purposes, the appending must be easy to toggle on and off for=
any single recipe. I would accomplish that by having it packed into a clas=
s which would make its decisions based on the meta data that is already in =
the recipe inheriting it.</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c=
olor: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c=
olor: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c=
olor: rgb(0, 0, 0);">
BR,</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c=
olor: rgb(0, 0, 0);">
Antti G=E4rding</div>
</body>
</html>
--_000_AS8PR08MB7251A410724D0D006312018ED5062AS8PR08MB7251eurp_--