... | ... | @@ -87,12 +87,10 @@ how GHC is *built*. We use both MSYS and Cygwin as build environments for |
|
|
GHC; both work fine, though MSYS is rather lighter weight.
|
|
|
|
|
|
|
|
|
In your build tree, you build a compiler called `ghc-inplace`. It
|
|
|
uses the `gcc` that you specify using the
|
|
|
`--with-gcc` flag when you run
|
|
|
`configure` (see below).
|
|
|
The makefiles are careful to use `ghc-inplace` (not `gcc`)
|
|
|
to compile any C files, so that it will in turn invoke the correct `gcc` rather that
|
|
|
In your build tree, the compiler you build uses the `gcc` that you specify using the
|
|
|
`--with-gcc` flag when you run `configure` (see below).
|
|
|
The makefiles are careful to use the right gcc, either via the in-place ghc or directly,
|
|
|
to compile any C files, so that we use correct `gcc` rather than
|
|
|
whatever one happens to be in your path. However, the makefiles do use whatever `ld`
|
|
|
and `ar` happen to be in your path. This is a bit naughty, but (a) they are only
|
|
|
used to glom together .o files into a bigger .o file, or a .a file,
|
... | ... | @@ -182,8 +180,7 @@ Many programs, including GHC itself and hsc2hs, need to find associated binaries |
|
|
For *installed* programs, the strategy depends on the platform. We'll use
|
|
|
GHC itself as an example:
|
|
|
|
|
|
- On Unix, the command `ghc` is a shell script, generated by adding installation
|
|
|
paths to the front of the source file `ghc.sh`,
|
|
|
- On Unix, the command `ghc` is a shell script, generated by Cabal from `ghc/ghc.wrapper`,
|
|
|
that invokes the real binary, passing "-B*path*" as an argument to tell `ghc`
|
|
|
where to find its supporting files.
|
|
|
- On vanilla Windows, it turns out to be much harder to make reliable script to be run by the
|
... | ... | |