On Fri, Sep 14, 2012 at 12:58:28PM +0100, Richard Purdie wrote: > On Thu, 2012-09-13 at 07:22 -0700, Chris Larson wrote: > > On Thu, Sep 13, 2012 at 6:06 AM, Otavio Salvador > > <ota...@ossystems.com.br> wrote: > > > On Thu, Sep 13, 2012 at 9:19 AM, Björn Stenberg <b...@enea.com> wrote: > > >> Khem Raj wrote: > > >>> I agree but then 1.7 GB is noticeably huge too and it will only become > > >>> larger in future so I don't think fetching from git will be a good > > >>> solution > > >>> for gcc ever. > > >> > > >> Can we use shallow clones? A quick test of gcc-4.7 gave me a 308 MB > > >> tar.gz when cloned with --depth 1. > > > > > > I did not check if the fetcher has this support but it would be a > > > nice solution. > > > > Shallow clones won't be able to support SRCREV properly, as you can > > only clone shallowly from HEAD, not from an arbitrary point in > > history, AFAIK. > > Right, shallow clones are a can of worms from a variety of angles. > > My current thinking is a ;allowsinglerev=1 parameter to the git fetcher > which: > > a) Generates tarballs of single git revisions if tarball generation is > turned on > b) Searches for single revision tarballs before trying the main checkout > approach. > > This would mean that WORKDIR may or may not have a .git directory for > any SRC_URI marked with this. I think we should all be able to live with > that and it shouldn't break too much?
Ah so finally fetch2 will have same functionality like fetch11 had? IIRC there is old buq report about this. > > Cheers, > > Richard > > > > _______________________________________________ > bitbake-devel mailing list > bitbake-de...@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/bitbake-devel -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
_______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core