%
% Version 2.02
% Feb 1997
-
-
\begin{onlystandalone}
This guide is intended for people who want to install or modify
programs from the Glasgow @fptools@ suite (as distinct from those
-who merely want to {\em run} them.
+who merely want to {\em run} them).
The whole install-and-make system has been completely re-done
between GHC 2.01 and 2.02, so it will be worth your while to re-read this guide
\item[The CVS repository.]
We make source distributions at the same time as binary distributions;
-i.e. infrequently. They should, however, be pretty throughly tested.
+i.e. infrequently. They should, however, be pretty thoroughly tested.
If you want more up-to-the minute (but less tested) source code then you
need to get access to our CVS repository.
architecture/manufacturer/operating-system combination,
such as @sparc-sun-solaris2.5.1@. Other common ones are
@alpha-dec-osf2@, @hppa1.1-hp-hpux9@, @i386-unknown-linux@,
-@i386-unknown-solaris2@, @i386-unknown-freebsd@,
-@m68k-sun-sunos4@, @mips-sgi-irix5@,
-@sparc-sun-sunos4@, @sparc-sun-solaris2@.
+@i386-unknown-solaris2@, @i386-unknown-freebsd@, @i386-unknown-cygwin32@,
+@m68k-sun-sunos4@, @mips-sgi-irix5@, @sparc-sun-sunos4@, @sparc-sun-solaris2@.
Bear in mind that certain ``bundles'', e.g. parallel Haskell, may not
work on all machines for which basic Haskell compiling is supported.
compilations. The native-code generator for iX86 platforms (e.g.,
Linux ELF) is {\em nearly} working; but is not turned on by default.
-Here's everything that's known about GHC ports, as of 2.01. We
+Here's everything that's known about GHC ports, as of 2.02. We
identify platforms by their ``canonical GNU-style'' names.
Note that some ports are fussy about which GCC version you use; or
\index{i386-*-linuxaout: registerised port}
%-------------------------------------------------------------------
-\item[\tr{i386-*-*bsd} (PCs running FreeBSD (and NetBSD?):]
-\index{i386-*-freebsd: registerised port}
-GHC~2.01 works registerised. Supports same set of bundles
-as the above.
+\item[\tr{i386-*-freebsd} (PCs running FreeBSD 2.2 or higher, and
+NetBSD/OpenBSD using FreeBSD emulation):] \index{i386-*-freebsd:
+registerised port} GHC~2.01 works registerised. Supports same set of
+bundles as the above.
\index{i386-*-freebsd: profiling---yes}
\index{i386-*-freebsd: concurrent---yes}
That should convert @Makefile.in@ to @Makefile@.
You can now either start using the tools {\em in-situ} without going
-through any installation process, just type @make config@ to set the
-tools up for this (you have to be in the @fptools@ directory). You'll
-also want to add the path which @make@ echoes to your @PATH@
-environment variable. This option is useful if you simply want to try
-out the package or you don't have the necessary priviledges (or
+through any installation process, just type @make in-place@ to set the
+tools up for this (you have to be in the @fptools@ directory for
+this). You'll also want to add the path which @make@ will now echo to
+your @PATH@ environment variable. This option is useful if you simply want
+to try out the package and/or you don't have the necessary priviledges (or
inclination) to properly install the tools locally. Note that if you
do decide to install the package `properly' at a later date, you have
-to go through the installation steps that
-follows.
+to go through the installation steps that follows.
To install an @fptools@ package, you'll have to do the following:
@Makefile.in@ to @Makefile@ and set all these variables directly
yourself. But do it right!}
-\item Run @make install@. This {\em should} works with ordinary Unix
+\item Run @make install@. This {\em should} work with ordinary Unix
@make@ -- no need for fancy stuff like GNU @make@.
\item \tr{rehash} (t?csh users), so your shell will see the new stuff
for doing shell-scripty tasks that involve lots of text processing.
It is pretty easy to install.
-(Perl~5 is the current version; GHC might be Perl~4 friendly, we've
-run into some trouble with our scripts on \tr{alpha-dec-osf\{1,2\}}
-using Perl~4 (patchlevel 36))
+Perl~5 is the current version; GHC should be Perl~4 friendly though.
+For Win32 platforms, Perl~5 is recommended, we even strongly suggest
+you pick up a port of Perl~5 for \tr{cygwin32}, as the common
+Hip/ActiveWare port of Perl is not Cool Enough for our purposes.
Perl should be put somewhere so that it can be invoked by the \tr{#!}
script-invoking mechanism. (I believe \tr{/usr/bin/perl} is preferred;
Two @fptools@ projects are worth a quick note at this point, because
they are useful for all the others:
\begin{itemize}
-\item @glafp-utils@ contains several small utilities
-which aren't particularly Glasgow-ish, but which are sometimes not
-available on Unix systems.
+\item @glafp-utils@ contains several utilities which aren't
+particularly Glasgow-ish, but Occasionally Indispensable.
+
\item @literate@ contains the Glasgow-built tools for generating
documentation. (The unoriginal idea is to be able to generate @latex@, @info@,
\end{itemize}
All the other directories are individual {\em projects} of the
@fptools@ system --- for example, the Glasgow Haskell Compiler (@ghc@),
-the Happy parser generator (@happy@), the @nofib@ benchmark stuite,
+the Happy parser generator (@happy@), the @nofib@ benchmark suite,
and so on.
You can have zero or more of these. Needless to say, some of them
are needed to build others. For example, you need @happy@ to build
@ghc@. You can either grab @happy@ too, or else you can use
-an version of @happy@ that's already installed on your system, or
+a version of @happy@ that's already installed on your system, or
grab a binary distribution of @happy@ and install it.
The important thing to remember is that even if you want only
except that each file is a symbolic link to the source file,
rather than being a copy of the source file. There are ``standard''
Unix utilities that make such copies, so standard that they go by
-different names: @lndir@, @mkshadowdir@ are two.
+different names: @lndir@, @mkshadowdir@ are two (If you don't have
+either, the source distribution includes sources for the \tr{X11}
+\tr{lndir} --- check out \tr{fptools/glafp-utils/lndir} ).
The build
tree does not need to be anywhere near the source tree in the
for the real work. Notably, it does @gmake depend@ in all directories
that contain programs. But @boot@ does more. For example, you can't
do @gmake depend@ in a directory of C program until you have converted
-the literate @.lh@ header files into standard @.h@ header files. Similarly, you convert a literate file to illiterate
-form until you have built the @literate@ tools. @boot@ takes care of these
+the literate @.lh@ header files into standard @.h@ header files.
+Similarly, you convert a literate file to illiterate form until you
+have built the @literate@ tools. @boot@ takes care of these
inter-directory dependencies.
-You should say @gmake boot@ right after configuring your build tree.
+You should say @gmake boot@ right after configuring your build tree,
+but note that this is a one-off, i.e., there's no need to re-do
+@gmake boot@ if you should re-configure your build tree at a later
+stage (no harm caused if you do though).
\item[@all@:] makes all the final target(s) for this Makefile.
Depending on which directory you are in a ``final target''
projects / ghc-hetmet.git / blobdiff