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