| Summary: | Correct commentary and possibly code assumptions about the existence of KMETA | ||
|---|---|---|---|
| Product: | [Yocto Project Subprojects] Kernel | Reporter: | Darren Hart <dvhart> |
| Component: | kernel-tooling | Assignee: | Bruce Ashfield <bruce.ashfield> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium | CC: | yp.kernel.watcher, yp.watcher |
| Version: | 1.3 | ||
| Target Milestone: | 1.4 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | --- | |
|
Description
Darren Hart
2012-11-13 21:50:38 UTC
For example, the comments in kernel-yocto.bbclass::do_kernel_checkout() suggest that a branch is required. KMETA definitely is not required in the current code, every linux-yocto-custom
is running with an empty KMETA variable.
I'm not sure what you are seeing in do_kernel_checkout(), but the only reference
to KMETA is protected:
if [ -n "${KMETA}" ]; then
git branch -a | grep -q ${KMETA}
if [ $? -ne 0 ]; then
echo "ERROR. The branch '${KMETA}' is required and was not"
echo "found. Ensure that the SRC_URI points to a valid linux-yocto"
echo "kernel repository"
exit 1
fi
fi
.. so if it's empty, it won't fire.
If KMETA is empty, the tools expect nothing, and meta doesn't need to exist
in directory form.
Maybe our notes are messed up on this defect, but I don't think there's anything
to document for this one with respect to branches and directories, but I could
use the defect to document how to switch/use KMETA. Does that sound ok ?
Perhaps just the comment then? # we can fix up the kernel repository, but at the least the meta # branch must be present. The machine branch may be created later. Maybe just something simple like "but the meta branch must be present if KMETA is defined" or similar. People coming up to speed on tooling are likely to read the above and assume a KMETA branch is required. That's reasonable .. I've modified the comment locally and will send it out with my next merge request. merged to oe-core. |