From: Martin Jansa <martin.jansa@gmail.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Chris Larson <clarson@kergoth.com>,
bitbake-devel <bitbake-devel@lists.openembedded.org>,
Otavio Salvador <otavio@ossystems.com.br>,
openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH 1/4] gcc: Switch SRC_URI to use svn
Date: Sat, 15 Sep 2012 08:25:52 +0200 [thread overview]
Message-ID: <20120915062552.GC11252@jama.jama.net> (raw)
In-Reply-To: <1347623908.13596.2.camel@ted>
[-- Attachment #1: Type: text/plain, Size: 1844 bytes --]
On Fri, Sep 14, 2012 at 12:58:28PM +0100, Richard Purdie 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@ossystems.com.br> wrote:
> > > On Thu, Sep 13, 2012 at 9:19 AM, Björn Stenberg <bjst@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?
Ah so finally fetch2 will have same functionality like fetch11 had?
IIRC there is old buq report about this.
>
> Cheers,
>
> Richard
>
>
>
> _______________________________________________
> bitbake-devel mailing list
> bitbake-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/bitbake-devel
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Martin Jansa <martin.jansa@gmail.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Chris Larson <clarson@kergoth.com>,
bitbake-devel <bitbake-devel@lists.openembedded.org>,
openembedded-core@lists.openembedded.org
Subject: Re: [bitbake-devel] [PATCH 1/4] gcc: Switch SRC_URI to use svn
Date: Sat, 15 Sep 2012 08:25:52 +0200 [thread overview]
Message-ID: <20120915062552.GC11252@jama.jama.net> (raw)
In-Reply-To: <1347623908.13596.2.camel@ted>
[-- Attachment #1: Type: text/plain, Size: 1844 bytes --]
On Fri, Sep 14, 2012 at 12:58:28PM +0100, Richard Purdie 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@ossystems.com.br> wrote:
> > > On Thu, Sep 13, 2012 at 9:19 AM, Björn Stenberg <bjst@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?
Ah so finally fetch2 will have same functionality like fetch11 had?
IIRC there is old buq report about this.
>
> Cheers,
>
> Richard
>
>
>
> _______________________________________________
> bitbake-devel mailing list
> bitbake-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/bitbake-devel
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
next prev parent reply other threads:[~2012-09-15 6:38 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-06 4:35 [PATCH 0/4] GCC fixes and updates Khem Raj
2012-09-06 4:35 ` [PATCH 1/4] gcc: Switch SRC_URI to use svn Khem Raj
2012-09-06 7:05 ` Koen Kooi
2012-09-12 2:44 ` Gary Thomas
2012-09-12 14:08 ` Richard Purdie
2012-09-12 15:34 ` Khem Raj
2012-09-13 12:19 ` Björn Stenberg
2012-09-13 13:06 ` Otavio Salvador
2012-09-13 14:22 ` Chris Larson
2012-09-14 11:58 ` [OE-core] " Richard Purdie
2012-09-14 11:58 ` Richard Purdie
2012-09-14 12:31 ` [OE-core] " Bruce Ashfield
2012-09-14 12:31 ` Bruce Ashfield
2012-09-14 12:36 ` [OE-core] " Otavio Salvador
2012-09-14 12:36 ` Otavio Salvador
2012-09-14 13:23 ` [OE-core] " Richard Purdie
2012-09-14 13:23 ` Richard Purdie
2012-09-14 13:25 ` [OE-core] " Otavio Salvador
2012-09-14 13:25 ` Otavio Salvador
2012-09-14 18:30 ` [OE-core] " McClintock Matthew-B29882
2012-09-14 18:30 ` [bitbake-devel] " McClintock Matthew-B29882
2012-09-15 6:25 ` Martin Jansa [this message]
2012-09-15 6:25 ` Martin Jansa
2012-09-06 4:35 ` [PATCH 2/4] gcc-4.7: Fix build for armv4/EABI and ppc/Os Khem Raj
2012-09-06 7:04 ` Koen Kooi
2012-09-06 4:35 ` [PATCH 3/4] arch-armv4.inc: On armv4 add --fix-v4bx to linker flags for kernel Khem Raj
2012-09-06 4:35 ` [PATCH 4/4] gcc-4.7: Backport libgcc fixes to appease the new build sequence Khem Raj
2012-09-09 6:02 ` [PATCH 0/4] GCC fixes and updates Khem Raj
2012-09-12 17:43 ` Saul Wold
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120915062552.GC11252@jama.jama.net \
--to=martin.jansa@gmail.com \
--cc=bitbake-devel@lists.openembedded.org \
--cc=clarson@kergoth.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=otavio@ossystems.com.br \
--cc=richard.purdie@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.