| Message ID | Pine.LNX.4.64.1105211620270.17692@digraph.polyomino.org.uk |
|---|---|
| State | New |
| Headers | show |
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 >
> 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
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
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 >
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.
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.
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.
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
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.
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
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}"