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

[Bruce Ashfield]

On Fri, Sep 14, 2012 at 7: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?

Sounds ok to me, and there are other uses like my nearly completed
'low bandwidth' yocto kernel recipe tweaks that should be able to leverage
something like this as well.

Cheers,

Bruce

>
> Cheers,
>
> Richard
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"