On Tue, 29 Mar 2011, Joseph S. Myers wrote: > Specifically, I propose removal of all support for building: ash autoconf > automake bash byacc bzip2 diff dosutils fileutils findutils find gawk > gettext gnuserv gzip hello indent libiconv libtool make mmalloc patch perl > prms rcs release recode sed send-pr shellutils tar textutils time uudecode > wdiff zip expect guile target-gperf target-examples target-qthreads. See > <http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01674.html> and followups > regarding reasons to keep a few packages in my original list that aren't > in the list above.
There's been push-back on libiconv and expect. Having looked more at tools in src, I see that cgen has code for using in-tree guile - but there are no associated dependencies at toplevel. I continue to think that the right model for cgen is a separate repository not containing any of the toplevel machinery or makefile rules referring outside the source directory; the rules for converting files in the toplevel cpu/ directory to C code used in opcodes etc. should go in the toplevel cpu/ directory (or elsewhere in binutils+gdb) and should be written to use an installed cgen binary. I've seen no push-back on the other packages here, and some of those not proposed for removal may nevertheness not be of current use. > 2. If you put directories from the GCC repository into your build, you > should expect GCC and its libraries to be built; toplevel should not > disable GCC on the grounds that GCC does not support a given target. There have been objections to this principle, so I propose a weaker: 2'. If the combination of directories present in the source tree would not build and install anything for the host or target (other than host libraries such as libiberty) then there should be an error at configure or build time. For example, a GCC source tree should not quietly build nothing because GCC isn't supported for the target; a binutils+gdb tree should not quietly build nothing for lack of BFD support, although it might build only a subset of binutils if ld and gdb aren't supported. > 6. Splitting up the src repository into multiple separate repositories > would be desirable as part of moving components away from CVS; different > projects should not be tied so closely to each other. I propose the > following as a natural division (moving anything out is complicated, with > various scripts, documentation etc. to update, but as noted here it should > be possible to move cgen and rda without any dependencies on other > projects): I'd still like comments on how > (h) utils - I don't know what to do with this directory or where it best > goes. relates to the other bits of src and where it would best go if src is split up. -- Joseph S. Myers jos...@codesourcery.com
