On 03/25/2011 11:59 AM, Joseph S. Myers wrote:
* 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).
The subdirectory code supporting in-tree runtest should be moved to the
toplevel anyway. Adding in-tree expect as a build module makes little
sense, though. It has a further dependency on tcl so it's not like your
reaching the bottom of the chain.
* 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.
This doesn't matter. You could in principle drop an out-of-tree texinfo
directory and use its makeinfo to build GCC.
So I think of the rules for it as a legacy.
Actually support for in-tree build tools is quite recent (2005-ish).
I don't see m4 as useful as a build tool (rather, it's used by autoconf),
It's used by libgfortran too.
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.
I agree that byacc can be dropped. I just wouldn't drop
flex/bison/m4/texinfo right now. I would like to separate removal of
obsolete Cygnus-tree remnants, from removal of features that we just
don't care about anymore. Building bison as a host module is the
former; building bison as a build module is the latter.
Paolo