Can't build on windows with a space in any of the used paths (stack,ghc,etc locations)

[ArthurHNL]

On Windows, when trying to build (after cloning) using the following command:

C:\Tools\haskell-ide-engine [master ≡]> stack .\install.hs cabal-build-all

Gives the following output:

install.hs: C:\Users\Arthur: createProcess: does not exist (No such file or directory)

I'm not really experienced with stack but it appears to be an issue with spaces in the path (my actual user folder is C:\Users\Arthur Heidt), the path appears to be cut off at the first space.

[fendor]

Do we know which command failed specifically? E.g. does stack .\install.hs help fail with the same error?
Or is this a cabal issue, e.g. cabal v2-build fails?

[ArthurHNL]

@fendor any stack .\install.hs fails:

C:\Tools\haskell-ide-engine [master ≡]> stack .\install.hs
install.hs: C:\Users\Arthur: createProcess: does not exist (No such file or directory)
C:\Tools\haskell-ide-engine [master ≡]> stack .\install.hs help
install.hs: C:\Users\Arthur: createProcess: does not exist (No such file or directory)

It probably doesn't matter but I'm using the integrated powershell terminal in vscode.

cabal v2-build also does not work but it gives some more diagonstics:

Failed to build network-3.0.1.1. The failure occurred during the configure
step.
Build log ( C:\Users\Arthur
Heidt\AppData\Roaming\cabal\logs\ghc-8.6.5\network-3.0.1.1-a7c0a2f72c1e0fc4564857678c584897c6b48964.log

):
Configuring network-3.0.1.1...
cabal.exe: The package has a './configure' script. If you are on Windows, This
requires a Unix compatibility toolchain such as MinGW+MSYS or Cygwin. If you
are not on Windows, ensure that an 'sh' command is discoverable in your path.
cabal.exe: Failed to build network-3.0.1.1 (which is required by
test:unit-test from haskell-ide-engine-0.12.0.0, test:wrapper-test from
haskell-ide-engine-0.12.0.0 and others). See the build log above for details.

It needs a unix toolchain but I believe it is included with the Haskell platform. Here is the file: network-3.0.1.1-a7c0a2f72c1e0fc4564857678c584897c6b48964.log

[fendor]

Sounds a bit like an issue upstream...
I know the issue with cabal, but no fix to it.
Stack should work though.

[ArthurHNL]

Except it does not.

[fendor]

I tried a minimal example on windows with a space in the path, it seems to work alright. So, this issue might indeed be caused by the install script.
What windows version, btw?

[ArthurHNL]

Windows 10 Pro x64 version 1903 (updated yesterday).

[ArthurHNL]

Fyi, I did not clone the repository into my user folder, I cloned it into C:\tools\haskell-ide-engine. The first time I ran the stack command it did some stuff before giving the error, now it immideatly crashes.

[fendor]

It was probably downloading ghc and building the install script.
I don't know where stack installs the script to, it might be into appdata and then tries to execute which now includes the username. More investigation required!

[jneira]

It needs a unix toolchain but I believe it is included with the Haskell platform.

re: cabal error
I am afraid that the configure step is not ghc related and you definitely need run cabal inside a msys console to build packages with it as the message suggests (network is required by many many haskell packages)
Once you have built network and it is cached, you can build the package in a ps console.

[jneira]

@ArthurHNL i would relocate all paths used by stack to directories out of your user dir:

• if it is not already set, point the stack root directory to X:\sr setting the %STACK_ROOT% env var to that value
• after a stack init to recreate files under the new %STACK_ROOT% dir if needed, change paths in %STACK_ROOT%\config.yaml:

local-bin-path: X:\bin
local-programs-path: X:\bin\stack

Of course you can replace X:\bin with whatever, but try to keep it short to avoid long paths issues.

[jneira]

@ArthurHNL have you had the opportunity to try those changes in stak config? Imo that stack configuration is good in general to develop with stack in windows.

[ArthurHNL]

@jneira I just tried the new configuration and it appears to be working :)

[jneira]

Great! I think we could close this, having a good workaround and being at the end a upstream issue.