Explicitly CCing Simon Marlow to ensure he sees this.
Alberto Valverde
Hello,
I'm trying to put together a GHC 8.0.1 cross-compiler with Template Haskell support. Initially to target Windows (32bits) from a Linux host but a similar procedure should enable to target other platforms too. I'd like to contribute the patches back so I'm asking for advice on how to implement it in order to increase the chances of them being accepted.
I've managed to get a working stage 1 cross-compiler with some patches which correctly builds all stage1 libs and GHC + stage 2 compiler and ghc-iserv.exe. However, compiling TH by using wine and ghc-iserver.exe fails because the file descriptor ids that GHC passes as arguments to "wine ghc-iserv.exe" don't make sense in the emulated windows world.
Ahh, right. Out of curiosity what toolchain are you using to build your stage 1 cross compiler?
I've hacked around this to test the feasibility of the approach by using stdin/stdout instead of creating new pipes and, surprisingly, managed to cross-compile a simple Template Haskell program.
Well done!
I'm considering using a socket for communicating between both processes as a more permanent solution but this would incur in a dependency on the "network" package. Would this be acceptable?
It would be nice if we could avoid it; GHC depending upon a library has the very unfortunate effect that any user code also needing to link against GHC or one of its libraries now has no choice in the version of that library. We go to some lengths to try to keep the dependency footprint of GHC small for this reason.
Named pipes have also crossed my mind but I'm not sure how well they're supported by wine.
It would be great if there were some way we could make this work with named pipes. Not only does it side-step the dependency issue, but it feels like the right way forward. Cheers, - Ben