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? -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
