On Fri, 25 Mar 2011, Paolo Bonzini wrote: > > 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. > > We can categorize them further this way: > > * May in principle be in use (or be put to some use for libelf): > fastjar libelf > > * Maybe turn it into a build tool, and it may even make sense: > dejagnu
dejagnu and expect used to have copies in the src tree but they were removed a long time ago, so I think of the rules for them both as a legacy (and I think those two go together). If they are removed, gcc subdirectory code supporting in-tree runtest and expect could be removed as well (it's quite possible other subdirectories in the gcc and src trees also have support for various components in-tree, that could be removed). > * Also present as build modules, host module makes little sense though: > bison byacc flex m4 texinfo texinfo used to have a copy in the GCC tree but was removed a long time ago; the src tree deliberately only has a copy of texinfo.tex in the toplevel texinfo directory. So I think of the rules for it as a legacy. I don't see m4 as useful as a build tool (rather, it's used by autoconf), nor the use of having both byacc and bison, and while build tools bison and flex could be used I doubt the real utility of building them in tree. -- Joseph S. Myers jos...@codesourcery.com
