objc patch (was Re: Problem to install GCC 4.6.0 with Objective-C language)

objc patch (was Re: Problem to install GCC 4.6.0 with Objective-C language)

[Nicola Pero]

>I get the error (this time the objc language is detected):
>
>/bin/bash ../../gcc-4.6.0/gcc/../move-if-change tmp-gi.list
>gtyp-input.list
>echo timestamp > s-gtyp-input
>build/gengtype  \
>                    -S ../../gcc-4.6.0/gcc -I gtyp-input.list -w
>gtype.state
>../../gcc-4.6.0/gcc/objc/objc-act.h:280: unidentified type
>`objc_ivar_visibility_kind'
> make[3]: *** [s-gtype] Error 1

Thanks German ... I could reproduce it.  You found a bug! :-)

Apologies for the bug, and thanks for sticking with us. ;-)

(you can ignore the following, it's for gcc-patches@gnu.org)

It's easy to reproduce the bug by simply deleting the gcc/cp directory from a GCC checkout,
then trying to compile with the c,objc languages enabled.  It fails with the error above,
because gengtype then reads objc/objc-act.h before c-family/c-common-objc.h.

The problem is in how the list of language-specific gtfiles is produced.  It is produced
in configure.ac, which:

 * will iterate over all the ${srcdir}/*/config-lang.in;

 * will source config-lang.in for all of them, regardless of whether they are enabled or not, and add $gtfiles to the list of gtfiles;

 * adds the C language last.

As a consequence, GTFILES is different depending on whether ${srcdir}/gcc/cp/ exists or not.  If it exists, usually the cp gtfiles
come before the objc ones (due to alphabetical ordering by the shell, I'd guess ?), and the cp gtfiles contain c-family/c-common-objc.h,
which is then processed before objc/objc-act.h.  If it doesn't exist, that doesn't happen, and it stops working. :-(

Here is a patch to fix it.  It just moves c-family/c-objc.h at the beginning of the objc gtfiles list, to make it independent of cp's
gtfiles list; with this, I can build c,objc with or without the gcc/cp directory. :-)

Ok to commit ?

Thanks

PS: In my view this fix is a candidate for backporting to 4.6.x; without it, the gcc-objc-4.6.x tarballs are unusable.

Index: ChangeLog
===================================================================
--- ChangeLog   (revision 173994)
+++ ChangeLog   (working copy)
@@ -1,3 +1,9 @@
+2011-05-21  Nicola Pero  <nicola.pero@meta-innovation.com>
+
+       * config-lang.in (gtfiles): Updated order of files to fix building
+       when the gcc/cp directory is missing, as in the case of some
+       release tarballs.
+
 2011-05-20  Nathan Froyd  <froydnj@codesourcery.com>
 
        * objc-act.c (objc_compare_types): Use function_args_iterator
Index: config-lang.in
===================================================================
--- config-lang.in      (revision 173994)
+++ config-lang.in      (working copy)
@@ -33,4 +33,7 @@
 # Most of the object files for cc1obj actually come from C.
 lang_requires="c"
 
-gtfiles="\$(srcdir)/objc/objc-act.h \$(srcdir)/objc/objc-act.c \$(srcdir)/objc/objc-runtime-shared-support.c \$(srcdir)/objc/objc-gnu-runtime-abi-01.c \$(srcdir)/objc/objc-next-runtime-abi-01.c \$(srcdir)/objc/objc-next-runtime-abi-02.c \$(srcdir)/c-parser.c \$(srcdir)/c-tree.h \$(srcdir)/c-decl.c \$(srcdir)/c-lang.h \$(srcdir)/c-objc-common.c \$(srcdir)/c-family/c-common.c \$(srcdir)/c-family/c-common.h \$(srcdir)/c-family/c-objc.h \$(srcdir)/c-family/c-cppbuiltin.c \$(srcdir)/c-family/c-pragma.h \$(srcdir)/c-family/c-pragma.c"
+# Order is important.  If you change this list, make sure you test
+# building without C++ as well; that is, remove the gcc/cp directory,
+# and build with --enable-languages=c,objc.
+gtfiles="\$(srcdir)/c-family/c-objc.h \$(srcdir)/objc/objc-act.h \$(srcdir)/objc/objc-act.c \$(srcdir)/objc/objc-runtime-shared-support.c \$(srcdir)/objc/objc-gnu-runtime-abi-01.c \$(srcdir)/objc/objc-next-runtime-abi-01.c \$(srcdir)/objc/objc-next-runtime-abi-02.c \$(srcdir)/c-parser.c \$(srcdir)/c-tree.h \$(srcdir)/c-decl.c \$(srcdir)/c-lang.h \$(srcdir)/c-objc-common.c \$(srcdir)/c-family/c-common.c \$(srcdir)/c-family/c-common.h \$(srcdir)/c-family/c-cppbuiltin.c \$(srcdir)/c-family/c-pragma.h \$(srcdir)/c-family/c-pragma.c"

Re: objc patch (was Re: Problem to install GCC 4.6.0 with Objective-C language)

[Ian Lance Taylor]

"Nicola Pero" <nicola.pero@meta-innovation.com> writes:

> +2011-05-21  Nicola Pero  <nicola.pero@meta-innovation.com>
> +
> +       * config-lang.in (gtfiles): Updated order of files to fix building
> +       when the gcc/cp directory is missing, as in the case of some
> +       release tarballs.

This is OK for trunk and 4.6 branch.

Thanks for figuring it out.

Ian

Remove separate tarballs (was: Re: objc patch (was Re: Problem to install GCC 4.6.0 with Objective-C language))

[Joseph S. Myers]

On Sat, 21 May 2011, Nicola Pero wrote:

> As a consequence, GTFILES is different depending on whether 
> ${srcdir}/gcc/cp/ exists or not.  If it exists, usually the cp gtfiles 
> come before the objc ones (due to alphabetical ordering by the shell, 
> I'd guess ?), and the cp gtfiles contain c-family/c-common-objc.h, which 
> is then processed before objc/objc-act.h.  If it doesn't exist, that 
> doesn't happen, and it stops working. :-(

Similar issues can exist with option handling (.opt files for all 
languages are processed whether the languages are enabled or not, meaning 
the flags for an option, or its existence for any mistaken uses in 
language-independent code, could depend on what source directories are 
present).

It's still desirable to avoid such unexpected dependencies, but what do 
people think of eliminating the separate tarballs for snapshots and 4.7 
and later releases, so that people need to go to more effort to get such 
not-widely-tested configurations with some directories missing?  I don't 
think the disk space reasons that may have applied for having smaller 
tarballs in 1997 are still particularly relevant.  linux-2.6.39.tar.bz2, 
for example, is 76096559 bytes, bigger than gcc-4.7-20110514.tar.bz2 at 
68048542 bytes, and the Linux kernel only has monolithic tarballs.

2011-05-21  Joseph Myers  <joseph@codesourcery.com>

	* gcc_release (adjust_dirs, maybe_build_tarfile): Remove.
	(build_tarfiles): Don't build separate files for languages and
	core.
	(build_diffs): Only build one set of diffs.
	(announce_snapshot): Only announce one tar file.
	(ADA_DIRS, CPLUSPLUS_DIRS, FORTRAN95_DIRS, GO_DIRS, JAVA_DIRS,
	OBJECTIVEC_DIRS, TESTSUITE_DIRS): Remove.  Don't adjust names
	relative to WORKING_DIRECTORY.

Index: gcc_release
===================================================================
--- gcc_release	(revision 173995)
+++ gcc_release	(working copy)
@@ -9,7 +9,7 @@
 # Contents:
 #   Script to create a GCC release.
 #
-# Copyright (c) 2001, 2002, 2006, 2009, 2010 Free Software Foundation.
+# Copyright (c) 2001, 2002, 2006, 2009, 2010, 2011 Free Software Foundation.
 #
 # This file is part of GCC.
 #
@@ -89,16 +89,6 @@
     error "Could not change directory to $1"
 }
 
-# Each of the arguments is a directory name, relative to the top
-# of the source tree.  Return another name for that directory, relative
-# to the working directory.
-
-adjust_dirs() {
-  for x in $@; do
-    echo `basename ${SOURCE_DIRECTORY}`/$x
-  done
-}
-
 # Build the source tree that will be the basis for the release
 # in ${WORKING_DIRECTORY}/gcc-${RELEASE}.
 
@@ -247,19 +237,6 @@
   FILE_LIST="${FILE_LIST} ${TARFILE}"
 }
 
-# Build a single tarfile if any of the directories listed exist,
-# but not if none of them do (because that component doesn't exist
-# on this branch).
-maybe_build_tarfile() {
-  dest=$1
-  shift
-  if [ $# != 0 -a -d "$1" ]; then
-    build_tarfile "$dest" "$@"
-  else
-    echo "Not building $dest tarfile"
-  fi
-}
-
 # Build the various tar files for the release.
 
 build_tarfiles() {
@@ -275,24 +252,6 @@
  
   # Build one huge tarfile for the entire distribution.
   build_tarfile gcc-${RELEASE} `basename ${SOURCE_DIRECTORY}`
-
-  # Now, build one for each of the languages.
-  maybe_build_tarfile gcc-ada-${RELEASE} ${ADA_DIRS}
-  maybe_build_tarfile gcc-g++-${RELEASE} ${CPLUSPLUS_DIRS}
-  maybe_build_tarfile gcc-fortran-${RELEASE} ${FORTRAN95_DIRS}
-  maybe_build_tarfile gcc-go-${RELEASE} ${GO_DIRS}
-  maybe_build_tarfile gcc-java-${RELEASE} ${JAVA_DIRS}
-  maybe_build_tarfile gcc-objc-${RELEASE} ${OBJECTIVEC_DIRS}
-  maybe_build_tarfile gcc-testsuite-${RELEASE} ${TESTSUITE_DIRS}
-   
-  # The core is everything else.
-  EXCLUDES=""
-  for x in ${ADA_DIRS} ${CPLUSPLUS_DIRS} ${FORTRAN95_DIRS}\
-	   ${GO_DIRS} ${JAVA_DIRS} ${OBJECTIVEC_DIRS} ${TESTSUITE_DIRS}; do
-    EXCLUDES="${EXCLUDES} --exclude $x"
-  done
-  build_tarfile gcc-core-${RELEASE} ${EXCLUDES} \
-    `basename ${SOURCE_DIRECTORY}`
 }
 
 # Build .gz files.
@@ -310,7 +269,7 @@
   old_vers=${old_file%.tar.bz2}
   old_vers=${old_vers#gcc-}
   inform "Building diffs against version $old_vers"
-  for f in gcc gcc-ada gcc-g++ gcc-fortran gcc-go gcc-java gcc-objc gcc-testsuite gcc-core; do
+  for f in gcc; do
     old_tar=${old_dir}/${f}-${old_vers}.tar.bz2
     new_tar=${WORKING_DIRECTORY}/${f}-${RELEASE}.tar.bz2
     if [ ! -e $old_tar ]; then
@@ -435,15 +394,7 @@
 
 <table>" > ${SNAPSHOT_INDEX}
        
-  snapshot_print gcc-${RELEASE}.tar.bz2 "Complete GCC (includes all of below)"
-  snapshot_print gcc-core-${RELEASE}.tar.bz2 "C front end and core compiler"
-  snapshot_print gcc-ada-${RELEASE}.tar.bz2 "Ada front end and runtime"
-  snapshot_print gcc-fortran-${RELEASE}.tar.bz2 "Fortran front end and runtime"
-  snapshot_print gcc-g++-${RELEASE}.tar.bz2 "C++ front end and runtime"
-  snapshot_print gcc-go-${RELEASE}.tar.bz2 "Go front end and runtime"
-  snapshot_print gcc-java-${RELEASE}.tar.bz2 "Java front end and runtime"
-  snapshot_print gcc-objc-${RELEASE}.tar.bz2 "Objective-C front end and runtime"
-  snapshot_print gcc-testsuite-${RELEASE}.tar.bz2 "The GCC testsuite"
+  snapshot_print gcc-${RELEASE}.tar.bz2 "Complete GCC"
 
   echo \
 "Diffs from "${BRANCH}"-"${LAST_DATE}" are available in the diffs/ subdirectory.
@@ -543,16 +494,6 @@
 # The directory that will contain the GCC sources.
 SOURCE_DIRECTORY=""
 
-# The directories that should be part of the various language-specific
-# tar files.  These are all relative to the top of the source tree.
-ADA_DIRS="gcc/ada libada gnattools"
-CPLUSPLUS_DIRS="gcc/cp libstdc++-v3"
-FORTRAN95_DIRS="gcc/fortran libgfortran"
-GO_DIRS="gcc/go libgo libffi"
-JAVA_DIRS="gcc/java libjava libffi boehm-gc"
-OBJECTIVEC_DIRS="gcc/objc gcc/objcp libobjc"
-TESTSUITE_DIRS="gcc/testsuite"
-
 # Non-zero if this is the final release, rather than a prerelease.
 FINAL=0
 
@@ -690,16 +631,6 @@
 WORKING_DIRECTORY="${DESTINATION}/gcc-${RELEASE}"
 SOURCE_DIRECTORY="${WORKING_DIRECTORY}/gcc-${RELEASE}"
 
-# Recompute the names of all the language-specific directories,
-# relative to the WORKING_DIRECTORY.
-ADA_DIRS=`adjust_dirs ${ADA_DIRS}`
-CPLUSPLUS_DIRS=`adjust_dirs ${CPLUSPLUS_DIRS}`
-FORTRAN95_DIRS=`adjust_dirs ${FORTRAN95_DIRS}`
-GO_DIRS=`adjust_dirs ${GO_DIRS}`
-JAVA_DIRS=`adjust_dirs ${JAVA_DIRS}`
-OBJECTIVEC_DIRS=`adjust_dirs ${OBJECTIVEC_DIRS}`
-TESTSUITE_DIRS=`adjust_dirs ${TESTSUITE_DIRS}`
-
 # Set up SVNROOT.
 if [ $LOCAL -eq 0 ]; then
     SVNROOT="svn+ssh://${SVN_USERNAME}@${SVN_SERVER}${SVN_REPOSITORY}"

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Remove separate tarballs (was: Re: objc patch (was Re: Problem to install GCC 4.6.0 with Objective-C language))

[Richard Guenther]

On Sat, May 21, 2011 at 6:33 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Sat, 21 May 2011, Nicola Pero wrote:
>
>> As a consequence, GTFILES is different depending on whether
>> ${srcdir}/gcc/cp/ exists or not.  If it exists, usually the cp gtfiles
>> come before the objc ones (due to alphabetical ordering by the shell,
>> I'd guess ?), and the cp gtfiles contain c-family/c-common-objc.h, which
>> is then processed before objc/objc-act.h.  If it doesn't exist, that
>> doesn't happen, and it stops working. :-(
>
> Similar issues can exist with option handling (.opt files for all
> languages are processed whether the languages are enabled or not, meaning
> the flags for an option, or its existence for any mistaken uses in
> language-independent code, could depend on what source directories are
> present).
>
> It's still desirable to avoid such unexpected dependencies, but what do
> people think of eliminating the separate tarballs for snapshots and 4.7
> and later releases, so that people need to go to more effort to get such
> not-widely-tested configurations with some directories missing?  I don't
> think the disk space reasons that may have applied for having smaller
> tarballs in 1997 are still particularly relevant.  linux-2.6.39.tar.bz2,
> for example, is 76096559 bytes, bigger than gcc-4.7-20110514.tar.bz2 at
> 68048542 bytes, and the Linux kernel only has monolithic tarballs.

I'm all for it.  The only tarball of significant size seems to be -java possibly
due to the fact that we ship pre-built classpath with it.  I suppose we have
to think of a way to deal with our aging java library anyway.

Maybe we can offer an additional compression format like lzma .xz
which brings down 4.5.3 compressed size from 66MB bz2 to 52MB (with -7).
But that can be decided separately.

Richard.

> 2011-05-21  Joseph Myers  <joseph@codesourcery.com>
>
>        * gcc_release (adjust_dirs, maybe_build_tarfile): Remove.
>        (build_tarfiles): Don't build separate files for languages and
>        core.
>        (build_diffs): Only build one set of diffs.
>        (announce_snapshot): Only announce one tar file.
>        (ADA_DIRS, CPLUSPLUS_DIRS, FORTRAN95_DIRS, GO_DIRS, JAVA_DIRS,
>        OBJECTIVEC_DIRS, TESTSUITE_DIRS): Remove.  Don't adjust names
>        relative to WORKING_DIRECTORY.
>
> Index: gcc_release
> ===================================================================
> --- gcc_release (revision 173995)
> +++ gcc_release (working copy)
> @@ -9,7 +9,7 @@
>  # Contents:
>  #   Script to create a GCC release.
>  #
> -# Copyright (c) 2001, 2002, 2006, 2009, 2010 Free Software Foundation.
> +# Copyright (c) 2001, 2002, 2006, 2009, 2010, 2011 Free Software Foundation.
>  #
>  # This file is part of GCC.
>  #
> @@ -89,16 +89,6 @@
>     error "Could not change directory to $1"
>  }
>
> -# Each of the arguments is a directory name, relative to the top
> -# of the source tree.  Return another name for that directory, relative
> -# to the working directory.
> -
> -adjust_dirs() {
> -  for x in $@; do
> -    echo `basename ${SOURCE_DIRECTORY}`/$x
> -  done
> -}
> -
>  # Build the source tree that will be the basis for the release
>  # in ${WORKING_DIRECTORY}/gcc-${RELEASE}.
>
> @@ -247,19 +237,6 @@
>   FILE_LIST="${FILE_LIST} ${TARFILE}"
>  }
>
> -# Build a single tarfile if any of the directories listed exist,
> -# but not if none of them do (because that component doesn't exist
> -# on this branch).
> -maybe_build_tarfile() {
> -  dest=$1
> -  shift
> -  if [ $# != 0 -a -d "$1" ]; then
> -    build_tarfile "$dest" "$@"
> -  else
> -    echo "Not building $dest tarfile"
> -  fi
> -}
> -
>  # Build the various tar files for the release.
>
>  build_tarfiles() {
> @@ -275,24 +252,6 @@
>
>   # Build one huge tarfile for the entire distribution.
>   build_tarfile gcc-${RELEASE} `basename ${SOURCE_DIRECTORY}`
> -
> -  # Now, build one for each of the languages.
> -  maybe_build_tarfile gcc-ada-${RELEASE} ${ADA_DIRS}
> -  maybe_build_tarfile gcc-g++-${RELEASE} ${CPLUSPLUS_DIRS}
> -  maybe_build_tarfile gcc-fortran-${RELEASE} ${FORTRAN95_DIRS}
> -  maybe_build_tarfile gcc-go-${RELEASE} ${GO_DIRS}
> -  maybe_build_tarfile gcc-java-${RELEASE} ${JAVA_DIRS}
> -  maybe_build_tarfile gcc-objc-${RELEASE} ${OBJECTIVEC_DIRS}
> -  maybe_build_tarfile gcc-testsuite-${RELEASE} ${TESTSUITE_DIRS}
> -
> -  # The core is everything else.
> -  EXCLUDES=""
> -  for x in ${ADA_DIRS} ${CPLUSPLUS_DIRS} ${FORTRAN95_DIRS}\
> -          ${GO_DIRS} ${JAVA_DIRS} ${OBJECTIVEC_DIRS} ${TESTSUITE_DIRS}; do
> -    EXCLUDES="${EXCLUDES} --exclude $x"
> -  done
> -  build_tarfile gcc-core-${RELEASE} ${EXCLUDES} \
> -    `basename ${SOURCE_DIRECTORY}`
>  }
>
>  # Build .gz files.
> @@ -310,7 +269,7 @@
>   old_vers=${old_file%.tar.bz2}
>   old_vers=${old_vers#gcc-}
>   inform "Building diffs against version $old_vers"
> -  for f in gcc gcc-ada gcc-g++ gcc-fortran gcc-go gcc-java gcc-objc gcc-testsuite gcc-core; do
> +  for f in gcc; do
>     old_tar=${old_dir}/${f}-${old_vers}.tar.bz2
>     new_tar=${WORKING_DIRECTORY}/${f}-${RELEASE}.tar.bz2
>     if [ ! -e $old_tar ]; then
> @@ -435,15 +394,7 @@
>
>  <table>" > ${SNAPSHOT_INDEX}
>
> -  snapshot_print gcc-${RELEASE}.tar.bz2 "Complete GCC (includes all of below)"
> -  snapshot_print gcc-core-${RELEASE}.tar.bz2 "C front end and core compiler"
> -  snapshot_print gcc-ada-${RELEASE}.tar.bz2 "Ada front end and runtime"
> -  snapshot_print gcc-fortran-${RELEASE}.tar.bz2 "Fortran front end and runtime"
> -  snapshot_print gcc-g++-${RELEASE}.tar.bz2 "C++ front end and runtime"
> -  snapshot_print gcc-go-${RELEASE}.tar.bz2 "Go front end and runtime"
> -  snapshot_print gcc-java-${RELEASE}.tar.bz2 "Java front end and runtime"
> -  snapshot_print gcc-objc-${RELEASE}.tar.bz2 "Objective-C front end and runtime"
> -  snapshot_print gcc-testsuite-${RELEASE}.tar.bz2 "The GCC testsuite"
> +  snapshot_print gcc-${RELEASE}.tar.bz2 "Complete GCC"
>
>   echo \
>  "Diffs from "${BRANCH}"-"${LAST_DATE}" are available in the diffs/ subdirectory.
> @@ -543,16 +494,6 @@
>  # The directory that will contain the GCC sources.
>  SOURCE_DIRECTORY=""
>
> -# The directories that should be part of the various language-specific
> -# tar files.  These are all relative to the top of the source tree.
> -ADA_DIRS="gcc/ada libada gnattools"
> -CPLUSPLUS_DIRS="gcc/cp libstdc++-v3"
> -FORTRAN95_DIRS="gcc/fortran libgfortran"
> -GO_DIRS="gcc/go libgo libffi"
> -JAVA_DIRS="gcc/java libjava libffi boehm-gc"
> -OBJECTIVEC_DIRS="gcc/objc gcc/objcp libobjc"
> -TESTSUITE_DIRS="gcc/testsuite"
> -
>  # Non-zero if this is the final release, rather than a prerelease.
>  FINAL=0
>
> @@ -690,16 +631,6 @@
>  WORKING_DIRECTORY="${DESTINATION}/gcc-${RELEASE}"
>  SOURCE_DIRECTORY="${WORKING_DIRECTORY}/gcc-${RELEASE}"
>
> -# Recompute the names of all the language-specific directories,
> -# relative to the WORKING_DIRECTORY.
> -ADA_DIRS=`adjust_dirs ${ADA_DIRS}`
> -CPLUSPLUS_DIRS=`adjust_dirs ${CPLUSPLUS_DIRS}`
> -FORTRAN95_DIRS=`adjust_dirs ${FORTRAN95_DIRS}`
> -GO_DIRS=`adjust_dirs ${GO_DIRS}`
> -JAVA_DIRS=`adjust_dirs ${JAVA_DIRS}`
> -OBJECTIVEC_DIRS=`adjust_dirs ${OBJECTIVEC_DIRS}`
> -TESTSUITE_DIRS=`adjust_dirs ${TESTSUITE_DIRS}`
> -
>  # Set up SVNROOT.
>  if [ $LOCAL -eq 0 ]; then
>     SVNROOT="svn+ssh://${SVN_USERNAME}@${SVN_SERVER}${SVN_REPOSITORY}"
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
>

Re: Remove separate tarballs (was: Re: objc patch (was Re: Problem to install GCC 4.6.0 with Objective-C language))

[Nicola Pero]

> Maybe we can offer an additional compression format like lzma .xz
> which brings down 4.5.3 compressed size from 66MB bz2 to 52MB (with  
> -7).
> But that can be decided separately.

Yes ... on the other hand, this does not address the other issue,  
which is the
amount of disk space that you need to actually uncompress the  
tarballs :-(

Unpacking gcc-4.6.0.tar.xx requires about 600 MB.  Unpacking gcc- 
core-4.6.0.tar.xx
requires about 150 MB.  It's a big difference.

Compiling a few languages (eg, the C ones) may produce object/build  
files for about
400 MB or so, meaning if you download gcc-4.6.0 to get a C compiler  
you'll likely
need a minimum of 1 GB of disk space.  If you download gcc-core-4.6.0  
you may
get away with about 550 MB (and get the same compiler).

Maybe you could reduce the number of tarballs, but without going to  
the extreme
of having just one.  Eg, you could keep the testsuite (expands to  
approx 150MB) as
a separate tarball, and probably Java (due to its size, again expands  
to approx 150MB)
as a separate tarball too, while merging everything else into a single  
tarball (expanding
to approx 300 MB).  It may a reasonable compromise.

But I'm not sure, just mentioning the idea.  The testsuite seems  
particularly suitable
for being kept separate, as most end-users want to just use the  
software as opposed
to test it; moreover testing requires DejaGNU, which (depending on the  
platform) may
require lot more dependencies and work to install - unpacking an  
additional tarball
would be the least of your troubles.  And some users may appreciate  
saving 150 MB
of disk space. :-)

But I don't have a strong opinion either way.  I was just contributing  
some thoughts.  I'm fine
with whatever you decide. :-)

I generally like the idea of reducing the exposure to untested  
configurations with missing
directories.

Thanks

Re: Remove separate tarballs

[Gerald Pfeifer]

On Mon, 23 May 2011, Nicola Pero wrote:
> Yes ... on the other hand, this does not address the other issue, which 
> is the amount of disk space that you need to actually uncompress the 
> tarballs :-(
> 
> Unpacking gcc-4.6.0.tar.xx requires about 600 MB.  Unpacking
> gcc-core-4.6.0.tar.xx
> requires about 150 MB.  It's a big difference.

Hmm, I just see that Joseph now activated this change which I find
unfortunate, since...

> Maybe you could reduce the number of tarballs, but without going to the 
> extreme of having just one.  Eg, you could keep the testsuite (expands 
> to approx 150MB) as a separate tarball, and probably Java (due to its 
> size, again expands to approx 150MB) as a separate tarball too, while 
> merging everything else into a single tarball (expanding to approx 300 
> MB).  It may a reasonable compromise.

...at least having the testsuite and Java separate makes a lot of sense.

The vast majority of users does not need the former and the latter is
on the verge of becoming practically irrelevant.  As one datapoint, the
entire FreeBSD Ports Collection has a single(!) port relying on GCJ.


Also, changing this for older release branches as happened now does 
cause all sorts of fun (for dubious definitions of this word) for
distribution packagers. :-(


Joseph, may I ask to reconsider and at least keep the testsuite and
Java separate?

Gerald

Re: Remove separate tarballs

[Richard Guenther]

On Sun, May 29, 2011 at 3:07 AM, Gerald Pfeifer <gerald@pfeifer.com> wrote:
> On Mon, 23 May 2011, Nicola Pero wrote:
>> Yes ... on the other hand, this does not address the other issue, which
>> is the amount of disk space that you need to actually uncompress the
>> tarballs :-(
>>
>> Unpacking gcc-4.6.0.tar.xx requires about 600 MB.  Unpacking
>> gcc-core-4.6.0.tar.xx
>> requires about 150 MB.  It's a big difference.
>
> Hmm, I just see that Joseph now activated this change which I find
> unfortunate, since...
>
>> Maybe you could reduce the number of tarballs, but without going to the
>> extreme of having just one.  Eg, you could keep the testsuite (expands
>> to approx 150MB) as a separate tarball, and probably Java (due to its
>> size, again expands to approx 150MB) as a separate tarball too, while
>> merging everything else into a single tarball (expanding to approx 300
>> MB).  It may a reasonable compromise.
>
> ...at least having the testsuite and Java separate makes a lot of sense.
>
> The vast majority of users does not need the former and the latter is
> on the verge of becoming practically irrelevant.  As one datapoint, the
> entire FreeBSD Ports Collection has a single(!) port relying on GCJ.
>
>
> Also, changing this for older release branches as happened now does
> cause all sorts of fun (for dubious definitions of this word) for
> distribution packagers. :-(

Does it?

> Joseph, may I ask to reconsider and at least keep the testsuite and
> Java separate?

The separate testsuite I always found a bit odd as it only includes
gcc/testsuite but not the testsuites in the various target libraries.
So I'd rather have the testsuite not be split out.

For libjava I would argue to split out only libjava/classpath which
is what we drop in (in a slightly modified form?) from elsewhere.
So splitting that would eventually make sense (maybe even
with making java also compile w/o that classpath dir).

Richard.

> Gerald
>

Re: Remove separate tarballs

[Joseph S. Myers]

On Sun, 29 May 2011, Gerald Pfeifer wrote:

> ...at least having the testsuite and Java separate makes a lot of sense.
> 
> The vast majority of users does not need the former and the latter is

If building GCC from source, running tests is generally considered a good 
idea...

> on the verge of becoming practically irrelevant.  As one datapoint, the

 ... and while there may be a case for modifying what's on trunk of the 
repository, separate tarballs are a case where having rarely-used, 
rarely-tested different configurations (because the rest of the compiler 
may be affected by what disabled languages are present in the source tree, 
which is what led to this change) seems not justified by the limited space 
savings.  If you want to remove some directories from your source tree, 
you are still free to do so and to submit fixes for any problems found; 
it's just not encouraged.

> Also, changing this for older release branches as happened now does 
> cause all sorts of fun (for dubious definitions of this word) for
> distribution packagers. :-(

Nothing changed for release from previous branches, which use the script 
present on the branch in question; it's only snapshots that always use the 
trunk version of this script.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Remove separate tarballs

[Joseph S. Myers]

On Sun, 29 May 2011, Richard Guenther wrote:

> For libjava I would argue to split out only libjava/classpath which
> is what we drop in (in a slightly modified form?) from elsewhere.
> So splitting that would eventually make sense (maybe even
> with making java also compile w/o that classpath dir).

Splitting out only in the way that ECJ is split out, I think: ceasing to 
include it on trunk of the repository but supporting dropping in a 
separately made release from its separate repository.  Not making tarballs 
not contain parts of what you get in a default checkout.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Remove separate tarballs

[Andrew Haley]

On 05/29/2011 02:07 AM, Gerald Pfeifer wrote:
> 
> The vast majority of users does not need the former and the latter is
> on the verge of becoming practically irrelevant.  As one datapoint, the
> entire FreeBSD Ports Collection has a single(!) port relying on GCJ.

It's not quite as irrelevant as you think: The IcedTea bootrapping
process that's used to port OpenJDK depends on gcj.  The first thing
we have to do an any target is get gcj working.  I'm doing that right
now.

Andrew.

Re: Remove separate tarballs

[Gerald Pfeifer]

On Tue, 7 Jun 2011, Andrew Haley wrote:
>> The vast majority of users does not need the former and the latter is
>> on the verge of becoming practically irrelevant.  As one datapoint, the
>> entire FreeBSD Ports Collection has a single(!) port relying on GCJ.
> It's not quite as irrelevant as you think: The IcedTea bootrapping
> process that's used to port OpenJDK depends on gcj.  The first thing
> we have to do an any target is get gcj working.  I'm doing that right
> now.

Agreed, but how many users of GCC (even those building GCC from
scratch) do have a need for our Java support?  I am pretty sure
it's a minority, that's why I suggest to not put everything into
one large tarball but of course leave it available.

Gerald

Re: Remove separate tarballs

[Andrew Haley]

On 16/06/11 01:43, Gerald Pfeifer wrote:
> On Tue, 7 Jun 2011, Andrew Haley wrote:
>>> The vast majority of users does not need the former and the latter is
>>> on the verge of becoming practically irrelevant.  As one datapoint, the
>>> entire FreeBSD Ports Collection has a single(!) port relying on GCJ.
>> It's not quite as irrelevant as you think: The IcedTea bootrapping
>> process that's used to port OpenJDK depends on gcj.  The first thing
>> we have to do an any target is get gcj working.  I'm doing that right
>> now.
> 
> Agreed, but how many users of GCC (even those building GCC from
> scratch) do have a need for our Java support?  I am pretty sure
> it's a minority, that's why I suggest to not put everything into
> one large tarball but of course leave it available.

There is a world of difference between not being used by many and
being practically irrelevant, which is what you claimed.  gcj is not
irrelevant: it is still a crucial link in the free software
infrastructure.  As long as it doesn't suffer bitrot, it doesn't much
matter whether gcj is a part of a single gcc tarball or not.

Andrew.

Re: Remove separate tarballs

[Gerald Pfeifer]

On Thu, 16 Jun 2011, Andrew Haley wrote:
> As long as it doesn't suffer bitrot, it doesn't much matter whether
> gcj is a part of a single gcc tarball or not.

That may be the case for most GNU/Linux distros.  On Gentoo or FreeBSD, 
for example, thousands and thousands of users (of the FreeBSD ports and
however the Gentoo equivalent is called) will end up downloading the bits
without using them.

Gerald