| Summary: |
Integrate the fetcher with a gitexternalsrc class for large team development |
| Product: |
[Build System, Metadata & Runtime] BitBake
|
Reporter: |
Jason Wessel <jason.wessel> |
| Component: |
bitbake | Assignee: |
Richard Purdie <richard.purdie> |
| Status: |
RESOLVED
FIXED
|
QA Contact: |
Lucian Musat <georgex.l.musat> |
| Severity: |
enhancement
|
|
|
| Priority: |
Medium
|
CC: |
bogdanx.a.voiculescu, poky.bs.watcher, poky.watcher
|
| Version: |
unspecified | |
|
| Target Milestone: |
1.9 | |
|
| Hardware: |
All | |
|
| OS: |
Multiple | |
|
| Whiteboard: |
|
|
OS type for building Yocto:
|
---
|
Type of Regression:
|
---
|
|---|
|
Verified:
|
|
Documentation change:
|
Yes (doc changes required)
|
|---|
In a large team setting is often more desirable to use an external source project. The externalsrc.bbclass today disables all the setscene tasks and integration with the fetcher. For a large team the CM integration with the fetcher is much more desirable for a couple of reasons. 1) sstate resuse 2) branch and track changes in the external git area It would be ideal to allow a recipe to operate with either AUTOREV or a specific rev but instead of looking at the upstream to look for any of the revision information in the local archive. The requirements for the gitexternalsrc: 1) The fetcher looks locally instead of remotely ** It might be nice to optionally fetch the remote upstream in the case that 2) If using a specific rev, it will get checked out at fetch time just like an upstream recipe would work 3) Allow for a separated build area if needed or allow for an in-tree build 4) Conditionally, allow for a cleanup rule which will actually clean up using operations like "git clean -f -d" 5) sstate works properly 6) Allow the ls-remote to be local for computation of recipes that use a SRCREV in the version and or name