From 257b5bc206944f19c3dc2f46d44b4b871d044fd7 Mon Sep 17 00:00:00 2001 From: simonmar Date: Wed, 8 Nov 2000 10:22:03 +0000 Subject: [PATCH] [project @ 2000-11-08 10:22:03 by simonmar] document options to ./configure. --- docs/building/building.sgml | 204 ++++++++++++++++++++++++++----------------- 1 file changed, 124 insertions(+), 80 deletions(-) diff --git a/docs/building/building.sgml b/docs/building/building.sgml index 3836d23..e9d09f8 100644 --- a/docs/building/building.sgml +++ b/docs/building/building.sgml @@ -547,8 +547,8 @@ standard source distribution. Autoconf builds the configure script from configure.in and aclocal.m4. -If you modify either of these files, you'll need Autoconf to rebuild -configure. +If you modify either of these files, you'll need +autoconf to rebuild configure. @@ -879,89 +879,133 @@ You set the configuration using a three-step process. Step 1: get ready for configuration. - -Change directory to -$(FPTOOLS_TOP) and issue the command autoconfautoconf (with -no arguments). This GNU program converts $(FPTOOLS_TOP)/configure.in -to a shell script called $(FPTOOLS_TOP)/configure. - - - -Some projects, including GHC, have their own configure script. If -there's an -$(FPTOOLS_TOP)/<project>/configure.in, -then you need to run autoconf in that directory too. - - - -Both these steps are completely platform-independent; they just mean -that the human-written file (configure.in) can be short, although -the resulting shell script, configure, and mk/config.h.in, are -long. - - - -In case you don't have autoconf we distribute the results, -configure, and mk/config.h.in, with the source distribution. They -aren't kept in the repository, though. - - - -Step 2: system configuration. - - -Runs the newly-created configure script, thus: + Change directory to + $(FPTOOLS_TOP) and + issue the command + autoconfautoconf + (with no arguments). This GNU program converts + $(FPTOOLS_TOP)/configure.in + to a shell script called + $(FPTOOLS_TOP)/configure. + + + Some projects, including GHC, have their own + configure script. If there's an + $(FPTOOLS_TOP)/<project>/configure.in, + then you need to run autoconf in that + directory too. + + Both these steps are completely + platform-independent; they just mean that the + human-written file (configure.in) + can be short, although the resulting shell script, + configure, and + mk/config.h.in, are long. + + In case you don't have autoconf + we distribute the results, configure, + and mk/config.h.in, with the source + distribution. They aren't kept in the repository, + though. + + + + + Step 2: system configuration. + + Runs the newly-created + configure script, thus: -./configure +./configure args -configure's mission is to scurry round your -computer working out what architecture it has, what operating system, -whether it has the vfork system call, where -yacc is kept, whether gcc is -available, where various obscure #include files -are, whether it's a leap year, and what the systems manager had for -lunch. It communicates these snippets of information in two ways: - - - - - - - - - It translates mk/config.mk.inconfig.mk.in to -mk/config.mkconfig.mk, substituting for things between -``@'' brackets. So, ``@HaveGcc@'' will be replaced by -``YES'' or ``NO'' depending on what configure finds. -mk/config.mk is included by every Makefile (directly or indirectly), -so the configuration information is thereby communicated to all -Makefiles. - - - - - - - It translates mk/config.h.inconfig.h.in to -mk/config.hconfig.h. The latter is #included by various C -programs, which can thereby make use of configuration information. + configure's mission is to + scurry round your computer working out what architecture + it has, what operating system, whether it has the + vfork system call, where + yacc is kept, whether + gcc is available, where various + obscure #include files are, + whether it's a leap year, and what the systems manager + had for lunch. It communicates these snippets of + information in two ways: + + + + + It translates + mk/config.mk.inconfig.mk.in + to + mk/config.mkconfig.mk, + substituting for things between + ``@'' brackets. So, + ``@HaveGcc@'' will be replaced by + ``YES'' or + ``NO'' depending on what + configure finds. + mk/config.mk is included by + every Makefile (directly or indirectly), so the + configuration information is thereby communicated to + all Makefiles. + + + + It translates + mk/config.h.inconfig.h.in + to + mk/config.hconfig.h. + The latter is #included by + various C programs, which can thereby make use of + configuration information. + + + + configure takes some optional + arguments. Use ./configure --help to + get a list of the available arguments. Here are some of + the ones you might need: + + + + --with-ghc=path + --with-ghc + + + Specifies the path to an installed GHC which + you would like to use. This compiler will be used + for compiling GHC-specific code (eg. GHC itself). + This option cannot be + specified using build.mk (see + later), because configure needs + to auto-detect the version of GHC you're using. + The default is to look for a compiler named + ghc in your path. + + + + + --with-hc=path + --with-hhc + + + Specifies the path to any installed Haskell + compiler. This compiler will be used for + compiling generic Haskell code. The default is to + use ghc. + + + + + configure caches the results of + its run in config.cache. Quite + often you don't want that; you're running + configure a second time because + something has changed. In that case, simply delete + config.cache. + + - - - - - - - - -configure caches the results of its run in config.cache. Quite -often you don't want that; you're running configure a second time -because something has changed. In that case, simply delete -config.cache. - - Step 3: build configuration. -- 1.7.10.4