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

Otavio Salvador otavio at ossystems.com.br
Fri Sep 14 12:36:29 UTC 2012


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?

-- 
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




More information about the bitbake-devel mailing list