| Summary: |
Add a class which allows buiding git upstream versions of code using BBCLASSEXTEND |
| Product: |
[Build System, Metadata & Runtime] OE-Core
|
Reporter: |
Richard Purdie <richard.purdie> |
| Component: |
core | Assignee: |
Ross Burton <ross.burton> |
| Status: |
RESOLVED
FIXED
|
QA Contact: |
|
| Severity: |
enhancement
|
|
|
| Priority: |
Medium+
|
CC: |
meta.mr.watcher, meta.watcher, tim.orling
|
| Version: |
2.1 | |
|
| Target Milestone: |
2.3 M3 | |
|
| Hardware: |
x86 | |
|
| OS: |
Multiple | |
|
| Whiteboard: |
|
|
OS type for building Yocto:
|
---
|
Type of Regression:
|
---
|
|---|
|
Verified:
|
|
Documentation change:
|
Yes (doc changes required)
|
|---|
In many cases we have a latest version recipe and also a _git.bb recipe which builds a version taken from the upstream scm. We also have users who bbappend our base recipes to get latest upstream versions. I'd like to explore whether we could put this metadata about where the upstream git repo is, into the main recipe to make some of these usages easier. Another benefit could potentially be a comeback of "poky-bleeding" where the idea was to test upstream code changes so we could react to them, before they make it into release tarballs. The idea would be a gitupstream.bbclass which would: * Rename GITSRC_URI to SRC_URI * Rename GITSRCREV to SRCREV * Set ${S} = ${WORKDIR}/git * Set DEFAULT_PREFERENCE = "-1" * Update PV to add +git${SRVPV} It might optionally be able to so some kind of search and replace on SRC_URI to place the git upstream in there for complex recipes, I'm undecided about this right now. It would be activated by the user marking up the recipe with GITSRC_URI and GITSRCREV and then adding "gitupstream" to BBCLASSEXTEND. I'm sure there are some issues we'll run into and it won't be quite this simple but I thought the idea worth documenting and perhaps investigating.