./validate --hadrian doesn't quite work on Windows
On my Windows machine, using an msys2 shell as advised by the Windows-specific pages of GHC's trac, I managed to get ./validate --hadrian
(from this MR) to go pretty far. I did manage to make it produce a binary distribution after some serious wrangling, to have it installed somewhere nearby and it ends up choking on this command which tries to configure an xhtml
build using Setup.hs
scripts.
When I looked at the verbose output, I ended up seeing that Cabal calls findProgramVersion
for the ghc that I pass using --with-ghc=...
, with --numeric-version
as the only argument. And this ends up returning ""
-- which is what's returned when exceptions are thrown apparently, judging from findProgramVersion's implementation.
Now, where this gets "interesting" is that I've tried to run ./Setup configure --with-ghc=X
for different values of X
...
- (1)
./Setup configure --with-ghc=/path/to/ghc/tree/_validatebuild/stage1/bin/ghc
works - (2)
./Setup configure --with-ghc=/path/to/ghc/tree/_validatebuild/bindist/ghc-8.6.20190220/bin/ghc
works - (3)
./Setup configure --with-ghc=/path/to/ghc/tree/bindisttest/install dir/bin/ghc
**doesn't work** (3 spaces betweeninstall
anddir
) - (4)
./Setup configure --with-ghc=/path/to/ghc/tree/a/b/bin/ghc
**doesn't work**
(1) is our stage 2 GHC executable, the real one, produced right at this path.
(2) is a copy of (1) that we put under this bindist/ghc-X.Y.Z/
dir, which we end up putting wholesale in an archive.
(3) is where ./validate
(whether with --hadrian
or not) installs binary distributions. The install process goes fine, I can even use the GHC in question and evaluate .../bin/ghc -e 'Data.Text.IO.putStrLn (Data.Text.pack "hello")'
without any problem, or get the expected output with .../bin/ghc --numeric-version
. But the configure
step just won't have it. I initially thought this was due to the directory with a space in it, one way or another, so I decided to try and install the bindist manually in a place with no spaces in the directory names, (4).
(4) doesn't work either though.
The main difference between 1) 2) on one hand, and 3) 4) on the other, is that in the first two cases I'm passing the path to an actual stage 2 GHC executable, while in the case of 3) and 4) I'm pointing to wrapper scripts, with the actual executables being under $topdir/lib/bin/
. I'm however not sure of what's going on, it seems to be like this should work, any help is appreciated.
Trac metadata
Trac field | Value |
---|---|
Version | 8.7 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | high |
Resolution | Unresolved |
Component | Build System (Hadrian) |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | hvr, snowleopard |
Operating system | |
Architecture |