[bitbake-devel] [OE-core] [PATCH 1/4] gcc: Switch SRC_URI to use svn

[McClintock Matthew-B29882]

On Fri, Sep 14, 2012 at 8:25 AM, Otavio Salvador
<otavio at ossystems.com.br> wrote:
> On Fri, Sep 14, 2012 at 10:23 AM, Richard Purdie
> <richard.purdie at 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.purdie at 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
>>> >> <otavio at ossystems.com.br> wrote:
>>> >> > On Thu, Sep 13, 2012 at 9:19 AM, Björn Stenberg <bjst at 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: otavio at ossystems.com.br  http://www.ossystems.com.br
> Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
>
> _______________________________________________
> bitbake-devel mailing list
> bitbake-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/bitbake-devel