On 12/05/2012 10:19 AM, Bruce Ashfield wrote: > 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.
Indeed not. In fact I think it is cleaner. The problem people face is when they have to use both mechanisms which appear to be ignorant of one another. > 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 :) No argument from me! > 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. I will update the docs, but I think we can do better. > 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. When the SRCREV specifies a commit that cannot be reached from the KBRANCH, we should be able to detect an inconsistency and fail right? -- Darren > > 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. >> >> > -- Darren Hart Intel Open Source Technology Center Yocto Project - Technical Lead - Linux Kernel _______________________________________________ linux-yocto mailing list linux-yo...@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
