Re: Documenting tools necessary for GCC [draft]

["Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>]

 > From: "Joseph S. Myers" <jsm28@cam.ac.uk>
 > 
 > The appropriate location is install.texi, as this documentation ought to 
 > be branched for releases to describe what is needed on the particular 
 > release branch.

Ok I'll move stuff to install.texi, though I'm far from a texi expert.
What section should it go in?


 > (And seek out all the places where version numbers are presently
 > documented in install.texi or elsewhere, to unify the documentation
 > of prerequisites.)

Yes worthwhile goal, but unlikely I'll find all places in the first go
around.  I think we'll have to find these over time and consolidate as
they are noticed.


 > > To make all languages in a cross-compiler or other configuration where
 > > 3-stage bootstrap is not performed, you need to start with an existing
 > > GCC binary because source code for language frontends other than C
 > > might use GCC extensions.
 > 
 > For building cross-compilers it must (as documented in install.texi) be
 > GCC 2.95 or later.  There is also the documentation of Ada prerequisites
 > in install.texi.

Thanks, I added 2.95 and an Ada section.



 > > A working Bourne (or compatible) shell, or
 > > GNU bash version 2.??? (or later)
 > 
 > Is there any actual reason to suppose bash 1.x defective?

<shrug>


 > > Necessary when running configure because some /bin/sh shells have bugs
 > > or disastrous corner-case performance problems.  Set CONFIG_SHELL in
 > > your environment to your "good" shell prior to running configure/make.
 > > Sometimes /bin/ksh is sufficient, sometimes it isn't.  See the
 > > host/target specific instructions for your platform, or use bash to be
 > > sure.
 > 
 > When is ksh defective?

David E mentioned that AIX ksh doesn't work, there may be others.  I
get intermitant failures on irix6.5 using ksh, but not on irix6.2.
OTOH, I use ksh on solaris2 and it always works, hence the hedging
about ksh.  I prefer not to document all the place where it works and
doesn't because this list will change in subtle ways every time we
modify the configure files.


 > > automake version ???
 > 
 > 1.4p? (whichever is the latest 1.4 patch release) but I don't know if this
 > is the case for all directories.

During the BOF, it was mentioned that we need four different and
incompatible versions of automake for the various directories.  (!!!)

I believe the plan is to upgrade all of them eventually to the latest
automake.  But I don't remember to what version (and it hasn't been
done yet, nor do I recall who if anyone volunteered to do it.)


 > > makeinfo version 4.2 (or later)
 > > 
 > > Necessary when modifying *.texi files to test your changes.
 > 
 > You need both makeinfo and texi2dvi from a Texinfo installation (version
 > 4.2 or later) - and a working TeX installation (no version number
 > relevant; any version now in use should suffice).

Hmm, I thought the dvi files were not part of the standard "make".
Don't you have to say "make dvi" ?  Also, I believe TeX is only
necessary if you "make dvi".  So I'll include them in their own
distinct section apart from making info files with makeinfo.



 > > ------------------------------------------------------
 > > perl version 5.??? (or later)
 > > 
 > > Necessary when regenerating Makefile dependencies in libiberty.
 > > Necessary when regenerating something with intl??? (pod2man???)
 > > Other stuff???
 > 
 > I'm sure that perl 5.6.1 or later suffices; earlier versions may work as
 > well if you upgrade the included Pod::Man.

Thanks, got it.


 > > patch version 2.5 (or later)
 > > 
 > > Necessary when applying patches, created with "diff", to one's own
 > > sources.
 > 
 > Some versions of patch have had problems with patches to binary files,
 > which are now included in the diffs between GCC releases (message
 > catalogs).  Could you test whether patch 2.5 does indeed work with these
 > patches (i.e., generates the same tree as the tarballs); if not, 2.5.4 may
 > need to be recommended instead.

I just wrote in 2.5.4.



 > Not included in the above list:
 > 
 > libtool (a tricky case because what's used is based on a dead CVS branch).

I don't understand this one.  Do we require someone hacking on GCC to
generate something with libtool when some file is modified?  If so,
which file(s) require (re)generation and touching which input files
make this necessary?


 > gettext (only for regenerating gcc.pot) (the most recent release isn't yet
 > needed, though quite possibly it has useful features for GCC; I don't know
 > what exactly the correct required version is; Zack can probably advise).

When does one need to regenerate gcc.pot?  I.e. when touching what
files?

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu