On 12-12-05 01:09 PM, Darren Hart wrote:
Some candid feedback from someone struggling with their build. They
specified a non-master branch on the SRC_URI but had not added a
KBRANCH, so bitbake fetched everything, but do_kernel_checkout checked
out the master branch.
This sort of disconnect between bitbake and the kern-tools is something
I'd like to see if we can cleanup. I understand the KBRANCH stuff enables
us to use the trees/tools outside of the bitbake environment, which is
a valid use case. However, when we're using bitbake, could we grab the
values from the SRC_URI and use those? Messy.
I understand what is being said .. but the following is also true:
It's no messier than counting on some long and arcane set of parameters
to a SRC_URI, buried in some layer with conditional dependencies.
Which is exactly what the current architecture is solving. It handles
far more complex cases then "fetch this branch, checkout this SHA and
build". Would you like to debug what I described above ? I know I
certainly don't want to.
I'm quite serious. To someone that's not familiar with oe, the
SRC_URIs are very hard to understand and debug, I get that comment
constantly as well :)
We can mitigate this with docs and the custom recipes as well, so
starting there and working out is a good incremental way to see
what we can do about making this consistent and clear.
The combination of do_validate_branches() and some peeking at the
SRC_URI directly can also help here, and I've already had this
in consideration for 1.4.
Cheers,
Bruce
> > My SRCREV is set to "AUTOREV", in which case bitbake prints the
SHA1
> > corresponding to the branch parameter in the git fetcher -
extremely
> > misleading.
>
> What would you expect it to do instead?
I guess it should be easy enough not to print any SHA1 sum at all,
especially not at the "compile" step rather than printing something and
building something else.
> > About to stop playing with the git fetcher parameters and modify
the recipe
> > instead. Lesson learned the very hard way.
>
> Unfortunately, you really need both. The SRCREV and and SRC_URI are
there to
> help bitbake know what to checkout and when tasks need to be re-run
> (when not to
> reuse sstate). The KBRANCH is part of an additional layer of
configuration
> introduced by the Yocto Project kern-tools.
>
> It is indeed rather confusing. I'd like to hear your thoughts on how
it
> could be improved.
Why the additional layer of configuration? I can't see when someone
would want to git fetch one branch/tag and build another.
_______________________________________________
linux-yocto mailing list
linux-yo...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
