Patchwork [1/4] gcc: Switch SRC_URI to use svn

login
register
mail settings
Submitter Khem Raj
Date Sept. 6, 2012, 4:35 a.m.
Message ID <5c54fcdb91d19909f8658b6a6e8d6e6cac934cf2.1346905978.git.raj.khem@gmail.com>
Download mbox | patch
Permalink /patch/36017/
State New
Headers show

Comments

Khem Raj - Sept. 6, 2012, 4:35 a.m.
svn tar balls are 96M as compared to 1.3G git tars
its unnessary to suck in that much of data.

Fixes [YOCTO #2908]

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 meta/recipes-devtools/gcc/gcc-4.7.inc |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
Koen Kooi - Sept. 6, 2012, 7:05 a.m.
Op 6 sep. 2012, om 06:35 heeft Khem Raj <raj.khem@gmail.com> het volgende geschreven:

> svn tar balls are 96M as compared to 1.3G git tars
> its unnessary to suck in that much of data.
> 
> Fixes [YOCTO #2908]
> 
> Signed-off-by: Khem Raj <raj.khem@gmail.com>
> ---
> meta/recipes-devtools/gcc/gcc-4.7.inc |    8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/meta/recipes-devtools/gcc/gcc-4.7.inc b/meta/recipes-devtools/gcc/gcc-4.7.inc
> index 84c230c..affbd54 100644
> --- a/meta/recipes-devtools/gcc/gcc-4.7.inc
> +++ b/meta/recipes-devtools/gcc/gcc-4.7.inc
> @@ -11,7 +11,7 @@ PR = "r11"
> # using 4.7.1.0 for upgrade path when we move past 4.7.2 release
> # then we should drop the last 0 as well.
> 
> -PV = "4.7.1.0+git${SRCPV}"
> +PV = "4.7.1.0+svn${SRCPV}"

Note that we can't switch back without either bumping PE or moving to 4.7.x. where x > 1
Gary Thomas - Sept. 12, 2012, 2:44 a.m.
On 2012-09-05 22:35, Khem Raj wrote:
> svn tar balls are 96M as compared to 1.3G git tars
> its unnessary to suck in that much of data.
>
> Fixes [YOCTO #2908]
>
> Signed-off-by: Khem Raj <raj.khem@gmail.com>

What about this patch?   Carrying around a 1.7GB (Sorry, Khem, that's the size of my tar ball!)
is a bit much, especially when that's what I send to my customers...

> ---
>   meta/recipes-devtools/gcc/gcc-4.7.inc |    8 ++++----
>   1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/meta/recipes-devtools/gcc/gcc-4.7.inc b/meta/recipes-devtools/gcc/gcc-4.7.inc
> index 84c230c..affbd54 100644
> --- a/meta/recipes-devtools/gcc/gcc-4.7.inc
> +++ b/meta/recipes-devtools/gcc/gcc-4.7.inc
> @@ -11,7 +11,7 @@ PR = "r11"
>   # using 4.7.1.0 for upgrade path when we move past 4.7.2 release
>   # then we should drop the last 0 as well.
>
> -PV = "4.7.1.0+git${SRCPV}"
> +PV = "4.7.1.0+svn${SRCPV}"
>
>   # BINV should be incremented after updating to a revision
>   # after a minor gcc release (e.g. 4.7.1 or 4.7.2) has been made
> @@ -21,7 +21,7 @@ PV = "4.7.1.0+git${SRCPV}"
>
>   BINV = "4.7.2"
>
> -SRCREV = "d07e24f4ab59f264d68d21838795349faab5dede"
> +SRCREV = "190218"
>   BRANCH = "gcc-4_7-branch"
>   FILESPATH = "${@base_set_filespath([ '${FILE_DIRNAME}/gcc-4.7' ], d)}"
>
> @@ -36,7 +36,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552 \
>                      file://COPYING.LIB;md5=2d5025d4aa3495befef8f17206a5b0a1 \
>   		   file://COPYING.RUNTIME;md5=fe60d87048567d4fe8c8a0ed2448bcc8"
>
> -SRC_URI = "git://github.com/mirrors/gcc.git;branch=${BRANCH};protocol=git \
> +SRC_URI = "svn://gcc.gnu.org/svn/gcc/branches;module=${BRANCH};protocol=http \
>   	   file://gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch \
>   	   file://100-uclibc-conf.patch \
>              file://gcc-uclibc-locale-ctype_touplow_t.patch \
> @@ -77,7 +77,7 @@ SRC_URI = "git://github.com/mirrors/gcc.git;branch=${BRANCH};protocol=git \
>   	   file://libtool.patch \
>   	  "
>
> -S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/git"
> +S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/${BRANCH}"
>   B = "${WORKDIR}/${BRANCH}/build.${HOST_SYS}.${TARGET_SYS}"
>
>   # Language Overrides
>
Richard Purdie - Sept. 12, 2012, 2:08 p.m.
On Tue, 2012-09-11 at 20:44 -0600, Gary Thomas wrote:
> On 2012-09-05 22:35, Khem Raj wrote:
> > svn tar balls are 96M as compared to 1.3G git tars
> > its unnessary to suck in that much of data.
> >
> > Fixes [YOCTO #2908]
> >
> > Signed-off-by: Khem Raj <raj.khem@gmail.com>
> 
> What about this patch?   Carrying around a 1.7GB (Sorry, Khem, that's the size of my tar ball!)
> is a bit much, especially when that's what I send to my customers...

I've been hoping to find some time to do something with the fetcher to
try and fix this corner we've ended up pinned into.

Ideally I'd like to see both gcc and eglibc using git, we have git in
ASSUME_PROVIDED and everything is optimal.

I'm not going to reach the release point without doing something about
this but I would like to stick with git if we can possibly help it.

Having to build subversion-native for critical path components is a
major pain and performance issue.

Cheers,

Richard
Khem Raj - Sept. 12, 2012, 3:34 p.m.
On Wednesday, September 12, 2012, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:
> On Tue, 2012-09-11 at 20:44 -0600, Gary Thomas wrote:
>> On 2012-09-05 22:35, Khem Raj wrote:
>> > svn tar balls are 96M as compared to 1.3G git tars
>> > its unnessary to suck in that much of data.
>> >
>> > Fixes [YOCTO #2908]
>> >
>> > Signed-off-by: Khem Raj <raj.khem@gmail.com>
>>
>> What about this patch?   Carrying around a 1.7GB (Sorry, Khem, that's
the size of my tar ball!)
>> is a bit much, especially when that's what I send to my customers...
>
> I've been hoping to find some time to do something with the fetcher to
> try and fix this corner we've ended up pinned into.
>
> Ideally I'd like to see both gcc and eglibc using git, we have git in
> ASSUME_PROVIDED and everything is optimal.
>
> I'm not going to reach the release point without doing something about
> this but I would like to stick with git if we can possibly help it.
>
> Having to build subversion-native for critical path components is a
> major pain and performance issue.
>

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. I was thinking we could Generate tar ball ourselves and put
it on yp mirror. And in future use up stream release tar balls.
> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Björn Stenberg - Sept. 13, 2012, 12:19 p.m.
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.
Otavio Salvador - Sept. 13, 2012, 1:06 p.m.
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.
Chris Larson - Sept. 13, 2012, 2:22 p.m.
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.
Bruce Ashfield - Sept. 14, 2012, 12:31 p.m.
On Fri, Sep 14, 2012 at 7:58 AM, Richard Purdie
<richard.purdie@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@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?

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@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Patch

diff --git a/meta/recipes-devtools/gcc/gcc-4.7.inc b/meta/recipes-devtools/gcc/gcc-4.7.inc
index 84c230c..affbd54 100644
--- a/meta/recipes-devtools/gcc/gcc-4.7.inc
+++ b/meta/recipes-devtools/gcc/gcc-4.7.inc
@@ -11,7 +11,7 @@  PR = "r11"
 # using 4.7.1.0 for upgrade path when we move past 4.7.2 release
 # then we should drop the last 0 as well.
 
-PV = "4.7.1.0+git${SRCPV}"
+PV = "4.7.1.0+svn${SRCPV}"
 
 # BINV should be incremented after updating to a revision
 # after a minor gcc release (e.g. 4.7.1 or 4.7.2) has been made
@@ -21,7 +21,7 @@  PV = "4.7.1.0+git${SRCPV}"
 
 BINV = "4.7.2"
 
-SRCREV = "d07e24f4ab59f264d68d21838795349faab5dede"
+SRCREV = "190218"
 BRANCH = "gcc-4_7-branch"
 FILESPATH = "${@base_set_filespath([ '${FILE_DIRNAME}/gcc-4.7' ], d)}"
 
@@ -36,7 +36,7 @@  LIC_FILES_CHKSUM = "file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552 \
                    file://COPYING.LIB;md5=2d5025d4aa3495befef8f17206a5b0a1 \
 		   file://COPYING.RUNTIME;md5=fe60d87048567d4fe8c8a0ed2448bcc8"
 
-SRC_URI = "git://github.com/mirrors/gcc.git;branch=${BRANCH};protocol=git \
+SRC_URI = "svn://gcc.gnu.org/svn/gcc/branches;module=${BRANCH};protocol=http \
 	   file://gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch \
 	   file://100-uclibc-conf.patch \
            file://gcc-uclibc-locale-ctype_touplow_t.patch \
@@ -77,7 +77,7 @@  SRC_URI = "git://github.com/mirrors/gcc.git;branch=${BRANCH};protocol=git \
 	   file://libtool.patch \
 	  "
 
-S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/git"
+S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/${BRANCH}"
 B = "${WORKDIR}/${BRANCH}/build.${HOST_SYS}.${TARGET_SYS}"
 
 # Language Overrides