On Fri, Sep 14, 2012 at 8:25 AM, Otavio Salvador <ota...@ossystems.com.br> wrote: > On Fri, Sep 14, 2012 at 10:23 AM, Richard Purdie > <richard.pur...@linuxfoundation.org> wrote: >> 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. > > By the way, there're any tool to clean the repo? (as we do for sstate-cache)?
scripts/clean-workdir cleans tmp/ - not sure about downloads -M > > -- > 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 > > _______________________________________________ > bitbake-devel mailing list > bitbake-de...@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/bitbake-devel _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
