On 12/05/2012 10:37 AM, Bruce Ashfield wrote: > On 12-12-05 01:34 PM, Darren Hart wrote: >> >> >> 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. > > So do I, see below. > >> >> >>> 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? > > Yes! It should fail like that currently, or at least it was intended > to fail. I can double check. > > Another thought that I had in 1.4 planning was that I do have access > to SRC_URI as a variable. As such, it's easy enough to check the > branch parameter that the fetch was passed, and detect if it doesn't > match KBRANCH. At that point we can either adjust KBRANCH or warn and > fail. > > I think that would go along way to making all the options apply the > same in both worlds. I'll prototype it shortly as part of my current > update queue.
That sounds like a good plan. Probably worth a bug/enhancement.Just to track that we're improving it if nothing else (as usability here has fairly high visibility). -- Darren > > Cheers, > > Bruce > >> >> -- >> 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 [email protected] https://lists.yoctoproject.org/listinfo/linux-yocto
