Initial windows support changes #48
Conversation
There was a problem hiding this comment.
@btrepp thanks!
I left some comments, but this should be pretty good, it looks like Travis is happy with this, so other OSes didn't break :)
Re the encoding problem: the issue might be in the line after the one you linked, in which we format the file inplace with Unicode. It's worth trying to remove that line (since it doesn't actually affect the result of the operation) and see if that fixes it. If not, then the problem is in how Turtle writes the file (which I find unlikely, since it's a basic hPutStr, source here)
|
So on the encoding issue, commenting out that line causes spago init to successfully complete (I think before the error I get was the format line you mentioned crashing) but on disk (opened with vim) the packages.dhall is still corrupted. This means spago install dies with the error init used to have. My other thoughts might be how the file is being embedded in Templates.hs (this appears to be literate haskell? well outside of my realm now :)). |
|
@btrepp oh right: we use |
Stack can't resolve dependencies correctly, recommended action was to add this line to stack.yaml. This may be better fixed upstream in turtle, as it seems stack comes with a newer version of win32 than turtle supports
The quotes caused issues on windows. Purs would complain about having no files. Changing the quote style fixes the command on windows
|
Thanks @btrepp! 👏 |
* Fixes stack build on windows Stack can't resolve dependencies correctly, recommended action was to add this line to stack.yaml. This may be better fixed upstream in turtle, as it seems stack comes with a newer version of win32 than turtle supports * Fixes bundle on windows The quotes caused issues on windows. Purs would complain about having no files. Changing the quote style fixes the command on windows
Co-authored-by: Fabrizio Ferrai <fabrizio.ferrai@gmail.com>
Solves getting compilation working, and making bundle work on windows as per #47
PR'd for code review purposes, I'm not sure if these are the best solutions and won't cause issues for non windows machines.
Unfortunately the encoding issue seems trickier, I'm not sure whether embedding the template or writing it to disk is causing the bad characters to be created, and my research into this has failed (so I might need a haskell guru to help fix this part). I could just change packages.dhall to be ascii, but I feel like this is weak solution as dhall supports unicode, so we should be able to work with that template file.