On Fri, 2012-09-14 at 09:36 -0300, Otavio Salvador wrote: > On Fri, Sep 14, 2012 at 8:58 AM, Richard Purdie > <richard.pur...@linuxfoundation.org> 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? > > We'll end with multiple tarballs, aren't we?
Yes. I'm not seeing that as a big problem for most of the usecases where we'd use this feature. You could skip shipping the big tarball of the whole repo at distribution time. Cheers, Richard _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
