Thanks for all the comments in this thread. I'm going to describe some
of the technical issues with making a GHC distribution that you can
bootstrap on any platform from a single set of sources below.
But first, let me explain our thinking on why we don't consider this a
priority: we aim to provide working binary distributions for 99.9% of
the potential users of GHC. Once you have a working binary of GHC,
building GHC again should be easy (if you run into problems, it's a
*high* priority from our point of view to fix it). For the other 0.1%,
we provide detailed instructions for porting GHC to your platform. It
works, but it's a tricky process. Once you have *one* working GHC, you
can build future versions probably for at least 4 years (we pull the
ladder up after ourselves to avoid #ifdef-hell in the compiler).
It may be that we don't have that 99.9% figure for 6.4, but when you
consider versions back to 5.02 (the oldest version we can build 6.4
with, I believe), it's probably true.
If your platform has a binary distribution, but you want to build GHC
using just a C compiler for idealogical reasons, you're slightly
misguided :-)
----------
Let me describe some of the technical issues with getting GHC to build
out of the box, with no GHC binary installed, on any platform.
Hopefully this will provide some useful pointers to anyone out there
with a burning desire to improve the GHC OOB experience.
How could we achieve a platform-independent bootstrap?
The only way I can see to do this is to have a set of completely
platform-independent .hc files to bootstrap from. Then the general plan
would be
- bootstrap unregisterised to get a stage1 compiler.
stage1 might be reduced functionality: no GHCi, perhaps
no native code gen, no template haskell.
- use this to build fully registerised libraries & stage2
To get our platform-independent .hc files, the contents of
ghc/compiler
ghc/lib
ghc/utils
libraries/base
libraries/Cabal
must all be compilable to platform-independent .hc code. That means
- No platform #ifdefs in the Haskell code in these directories
- No hsc2hs code in these directories
We have to eradicate all platform #ifdefs, because they give rise to
platform-varying .hc code. In practice, this will probably mean
translating some code from Haskell to C. hsc2hs is a similar problem -
that gives rise to platform-varying .hs code. Fortunately there is very
little hsc2hs code left in here - it gives rise to other porting
problems so we removed it.
Our job is slightly easier:
- As long as we still compile via-C, we can omit the native code
generator in stage1, and build it in stage2 only. That's a big
source of #ifdefs we don't have to worry about (arguably we
should just compile in all the variants of the NCG anyway).
However, our job is harder because
- ghc/compiler/main/Constants.hs contains a bunch of baked-in
constants such as the platform word-size. These would have
to be made dynamic - or at least turned into unsafe reads of
an external C variable.
Given that a majority of the #ifdefs are Unix-vs-Windows, we could
consider a partial solution, and settle for having two sets of .hc
files, one for Unix and one for Windows. We could further split the
Unix camp into 32-bit and 64-bit Unix, which makes the job even easier
(the Constants.hs problem partly goes away).
A few very rough figures:
- total platform #ifdefs in the relevant sources: 395
- after omitting the native code gen: 148
- after omitting Windows: 28
- after omitting GHCi: 21
and there are 3 .hsc files in libraries/base, but they aren't necessary
for bootstrapping.
Hmm, it's starting to look plausible. Constants.hs is the biggest
sticking point, and then hacking up the build system to do
bootstrapping.
Hope this has been of use to someone...
Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
