Few problems with building GHC

[Claus Reinke]

> I see, so I guess the short answer is "there's just no easy way to do it for
> now".  Perhaps I'll write a Perl script that will do it for me while waiting
> for a standardized solution.  The issue of source/binary version mismatches
> shouldn't be a problem as long as the source I copy over is the same source
> I built from right?  Or are you suggesting that sometimes the source is
> transformed during the build process before being compiled?

It isn't just a matter of scripting (you could 'cabal unpack' all your
installed packages somewhere), but of source code interpretation
being partially package-based (eg, if you have two packages providing
alternative implementations of the same modules, it is cabal's job to
organize the hiding of one while building or using the other; if you just
use ghc's import chasing over a list of import directories containing the 
sources of both packages, things are likely to fail). 

If you keep the sources around from the build, at least all the preprocessing 
and configuration will have been done and match the installed binaries.

If you get something working (for which editor, btw?), you might want 
to add your experiences to one of those tickets, or the wiki. It isn't that 
this would be impossible, just not trivial, so we have to keep adding 
information on possible solutions/issues until a viable design for a
standard solution emerges.

>> Are you sure you've configured for mingw? Otherwise the build
>> system will try to proceed in cygwin, as if for a unix platform.
> 
> I'm pretty sure I'm NOT configured for MinGW when I was trying to build
> under Cygwin.  I just assumed that the process would be completely
> independent of the mingw process.  What do I need to do configure the cygwin
> environment for MinGW?

Not configure cygwin, but configure the ghc build (so that it will pick
up mingw gcc/ld even while using cygwin sh/make/configure). See 
wiki:Building for details.

>>  However, building under MSYS everything works perfectly.  Is
>>> Cygwin just not supported, or do I need to change something here?  I don't
>>> see any point in cluttering up my system with tons of extra software like
>>> MinGW, msys, etc if Cygwin works fine.
>>
>> Mingw provides the C compiler, msys or cygwin the build tools.
>> Even under cygwin, you still need to configure to use the mingw
>> C compiler and linker (not the cygwin versions of these).
>>
>> Simon Marlow has recently cleaned up the build instructions
>> http://hackage.haskell.org/trac/ghc/wiki/Building
>>
>> If there's still anything missing or ambiguous in there, please provide
>> details, questions, or improve the wiki pages. We all like those
>> instructions to be accurate, for the next time we start from scratch!-)
> 
> Is there a way to download a windows binary distribution of GCC myself and
> have Cygwin use my version of GCC and Cygwin's version of all tools?  It
> just seems a little superfluous to have two unix environments (Cygwin and
> mingw) and two separate copies of GCC installed (since I already use windows
> GCC for other reasons)

mingw is a windows binary distribution of gcc/ld/.. (which create
    windows-native executables) - you need this.
msys and cygwin are unix-like environments (sh/make/configure/ ..) -
    you need exacty one of these.
cygwin has its own versions of gcc/ld (which generate cygwin-dependent
    executables*) - you don't need these (not likely to work for ghc builds).

Most of which I mentioned before, as does the wiki.

Claus

*cygwin's gcc/ld used to have a native mode, but the sources for
    that may not be in sync with the now separate mingw gcc/ld, may
    not do the same thing, and are not likely to work for ghc builds