X-Git-Url: http://git.megacz.com/?a=blobdiff_plain;ds=sidebyside;f=docs%2Fbuilding%2Fbuilding.xml;h=d0db332513abc11c8891073227db712d401f666c;hb=c838103b0636d8209d9d910db0a0328ee1682a39;hp=d1b203c3f9e056a375d3c2752e70afc7aa3494c0;hpb=cbc1b141e4564a84c1a02d69baf9fc5e328f9b93;p=ghc-hetmet.git
diff --git a/docs/building/building.xml b/docs/building/building.xml
index d1b203c..d0db332 100644
--- a/docs/building/building.xml
+++ b/docs/building/building.xml
@@ -165,10 +165,15 @@
supported method, and you may encounter difficulties. Full
instructions are in .
- Which version of GHC you need will depend on the
- packages you intend to build. GHC itself will normally
- build using one of several older versions of itself - check
- the announcement or release notes for details.
+ GHC can be built using either an earlier released
+ version of GHC (currently 5.04 and later are supported), or
+ bootstrapped using a GHC built from exactly the same
+ sources. Note that this means you cannot in general build
+ GHC using an arbitrary development snapshot, or a build from
+ say last week. It might work, it might not - we don't
+ guarantee anything. To be on the safe side, start your
+ build using the most recently released stable version of
+ GHC.
@@ -2351,24 +2356,25 @@ $ make install
Porting GHC
This section describes how to port GHC to a currenly
- unsupported platform. There are two distinct
- possibilities:
+ unsupported platform. To avoid confusion, when we say
+ “architecture” we are referring to the processor, and
+ we use the term “platform” to refer to the combination
+ of architecture and operating system.
+
+ There are two distinct porting scenarios:
- The hardware architecture for your system is already
- supported by GHC, but you're running an OS that isn't
- supported (or perhaps has been supported in the past, but
- currently isn't). This is the easiest type of porting job,
- but it still requires some careful bootstrapping. Proceed to
- .
+ Your platform is already supported, but you want to
+ compile up GHC using just a C compiler. This is a
+ straightforward bootstrap from HC files, and is described in
+ .
- Your system's hardware architecture isn't supported by
- GHC. This will be a more difficult port (though by comparison
- perhaps not as difficult as porting gcc). Proceed to .
+ Your platform isn't supported by GHC. You will need to
+ do an unregisterised bootstrap, proceed
+ to .
@@ -2389,25 +2395,40 @@ $ make install
later.
HC files are platform-dependent, so you have to get a set
- that were generated on the same platform. There
- may be some supplied on the GHC download page, otherwise you'll have to
- compile some up yourself, or start from
- unregisterised HC files - see .
+ that were generated on the same platform.
+ There may be some supplied on the GHC download page, otherwise
+ you'll have to compile some up yourself.
The following steps should result in a working GHC build
with full libraries:
- Unpack the HC files on top of a fresh source tree
- (make sure the source tree version matches the version of
- the HC files exactly!). This will
- place matching .hc files next to the
- corresponding Haskell source (.hs or
- .lhs) in the compiler subdirectory
- ghc/compiler and in the libraries
- (subdirectories of
+ Make a set of HC files. On an identical system with
+ GHC already installed, get a GHC source tree and put the
+ following in mk/build.mk:
+
+
+SRC_HC_OPTS = -H32m -O -fasm -Rghc-timing -keep-hc-files
+GhcLibHcOpts = -O
+GhcLibWays =
+SplitObjs = NO
+
+
+ Build GHC as normal, and then make
+ hc-file-bundle Project=ghc to creates the tar file
+ containing the hc files.
+
+
+
+ On the target system, unpack the HC files on top of a
+ fresh source tree (make sure the source tree version matches
+ the version of the HC files exactly!).
+ This will place matching .hc files next
+ to the corresponding Haskell source
+ (.hs or .lhs) in
+ the compiler subdirectory ghc/compiler
+ and in the libraries (subdirectories of
libraries).
@@ -2439,10 +2460,10 @@ $ make install
- Porting GHC to a new architecture
+ Porting GHC to a new platform
- The first step in porting to a new architecture is to get
- an unregisterised build working. An
+ The first step in porting to a new platform is to get an
+ unregisterised build working. An
unregisterised build is one that compiles via vanilla C only.
By contrast, a registerised build uses the following
architecture-specific hacks for speed:
@@ -2473,6 +2494,13 @@ $ make install
since unregisterised compilation is usually just a step on the
way to a full registerised port, we don't mind too much.
+ You should go through this process even if your
+ architecture is already has registerised support in GHC, but
+ your OS currently isn't supported. In this case you probably
+ won't need to port any of the architecture-specific parts of the
+ code, and you can proceed straight from the unregisterised build
+ to build a registerised compiler.
+
Notes on GHC portability in general: we've tried to stick
to writing portable code in most parts of the system, so it
should compile on any POSIXish system with gcc, but in our
@@ -2529,7 +2557,7 @@ $ ./configure --enable-hc-boot --enable-hc-boot-unregisterised
You might need to update
configure.in to recognise the new
- architecture, and re-generate
+ platform, and re-generate
configure with
autoreconf.
@@ -2647,7 +2675,7 @@ $ make boot stage=2 && make stage=2
$ make clean
$ rm .depend
$ make boot UseStage1=YES EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files'
-$ cd H/ghc/utils
+$ cd H/utils
$ make clean
$ make -k UseStage1=YES EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files'
@@ -2851,15 +2879,15 @@ Hello World!
GHCi
To support GHCi, you need to port the dynamic linker
- ($(GHC_TOP)/rts/Linker.c). The linker
- currently supports the ELF and PEi386 object file formats - if
- your platform uses one of these then things will be
- significantly easier. The majority of Unix platforms use the
- ELF format these days. Even so, there are some
+ ($(GHC_TOP)/rts/Linker.c). The
+ linker currently supports the ELF and PEi386 object file
+ formats - if your platform uses one of these then things will
+ be significantly easier. The majority of Unix platforms use
+ the ELF format these days. Even so, there are some
machine-specific parts of the ELF linker: for example, the
code for resolving particular relocation types is
machine-specific, so some porting of this code to your
- architecture will probaly be necessary.
+ architecture and/or OS will probaly be necessary.
If your system uses a different object file format, then
you have to write a linker — good luck!