On Thu, 24 Mar 2011, Paolo Bonzini wrote: > > One thing I wonder is if we can > > kill the toplevel support for building lots of miscellaneous tools that > > aren't in the gcc or src trees and that aren't libraries used by tools in > > those trees (such as the support for dropping a GMP source tree into a GCC > > source tree) either. There are plenty of packaging systems out there, but > > I'm not convinced it's any longer useful for this toplevel build/configure > > code to care about building autoconf, send-pr, rcs or guile, for example. > > Not sure about that. For sure, people are using in-tree GMP.
My question is really whether people are using *any* of the following in-tree (in a way that wouldn't better be served by either some other package management system, or by their maintaining a local fork of the GCC or src tree): bison byacc flex m4 texinfo ash autoconf automake bash bzip2 dejagnu diff dosutils fastjar fileutils findutils find gawk gettext libelf 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. Rules for GMP are directly useful to people building FSF GCC in a way that rules for those components aren't. I would note for a start that several of the names above are names for long-obsolete GNU packages (merged into coreutils or sharutils, for example), and that mmalloc was probably there because of formerly having been used by GDB a long time ago. -- Joseph S. Myers jos...@codesourcery.com
