GHC hacking in Windows -> too much pain

[Peter Tanski]

Simon Marlow wrote:
> Esa Ilari Vuokko wrote:
>>  * I noticed this with alex, but it's probably true for many other
>>    tools;  If there's spaces in path, configure/build will fail
>>    miserably.  I can't find any guidelines how this is supposed
>>    to be handled in configure/config.mk.in/suffix.mk/other makefiles.
>
> Our build system doesn't currently support putting the build tree  
> in a path that has spaces in it.  IIRC, we concluded that it was  
> too hard to get all the quoting right - you'd need quotes around  
> virtually all variables passed to external commands.  I bet this is  
> the situation for the fast majority of make-based build systems.

It is true for _all_ Make-based build systems, unless you employ the  
hack of filling whitespace with a non-whitespace character (used in  
libraries/Makefile and one of my own).  Make can't handle spaces  
because it only distinguishes words in the same way that  
Data.List.words does--quotes included.

Esa, I shouldn't recount the long discussions on this list regarding  
the build system here but we considered what do do about it and the  
general idea seems to be to move toward Cabal and keep the Make-based  
system only for porting to new platforms.  I haven't had the time I  
did before to get a new build system going but that will eventually  
happen (probably written in Erlang).  I originally wanted to use  
MSBuild on Windows, essentially a Visual Studio project, and Simon  
suggested I modify Cabal to output MSBuild files (they are written in  
XML).  If you are interested in a solution like that I will see what  
I can do about it.  The only problem is the monumental drudgery of  
working through all the special settings strewn through the  
Makefiles, and now Cabal.

>>  * If, for some reason, I get a working build configuration, and
>>    manage to get validate into testing phase; There's always bugs
>>    already, most often some of them randomly triggering.  Then
>>    validate just tells me I have bad tree and need to fix something.
>
> We do have a few Windows failures, I'll look into cleaning them up.
>
>> The common theme in problems I've ran into, is that they are  
>> something
>> related to buildsystem or errors that happen randomly.
>> Last night, trying to get build going, I had seven makefiles (or
>> related), configure.ac and aclocal.m4 open in my editor, not a single
>> haskell (or even c) file open!  And in the end it didn't even get  
>> past
>> stage 1.  This was ~20min active hacking and 2h+ waiting for builds
>> (but I used the waiting time to do other things.)
>>
>
> I know.  It's really painful, which is why I hardly ever use  
> Windows for development, unless I'm working on something Windows- 
> specific.  I can run validate in 25 mins on a decent x86/Linux box,  
> under Windows it takes more like 2 hours.  You'd probably be more  
> productive running Linux in a VM :-)
>
> I have spent a large part of today fighting with the Win32 API in  
> order to fix http://hackage.haskell.org/trac/ghc/ticket/1280.  To  
> do something that takes 2 lines in Unix.  Sigh.

I'm sorry about that.  While this does not affect the build system, I  
got the Windows-native build to the point where it would build  
libraries and ran into a bug (my own problem, Haskell-based) where  
the Windows-native GHC could not correctly determine dependencies (it  
would always fail as if you were trying to compile a program,  
complaining that the file does not match the (inferred) module name  
'Main' even though the option given was -M).  Before I had a chance  
to track it down I started a new job where I have been working very  
long hours for a product launch in September.  If you or anyone else  
is interested in what I have done I will package it up as a branch;  
otherwise it will sit around until I can dig up some free time.

Cheers,
Pete

P.S. Same time problem affected the replacement library.  I should  
fix up the current system a bit and get it to Thorkil soon since he  
has waited very patiently without complaint.