Details

This completes the work started in D4227 by using just 'getExecutablePath'
in ghc and ghc-pkg when building with base >= 4.11.0.

On the long term, we will be able to simply kill the existing code that
follows (or not) symlinks and just get this behaviour for free from
getExecutable. For now we however have to require base >= 4.11.0 to be able
to just use getExecutablePath under Windows, and use the current code when
building with an older base.

Original code by @alpmestan commandeering since patch has been stale
and bug remains open.

I'm wondering whether we could simply do without this rootDir function altogether and just use takeDirectory . takeDirectory, which is what the unix/osx implementation does, and this also appears to be what we do _on Windows_ in ghc-pkg's Main module (see my changes to that file). @Phyx It seems to me that this is all equivalent, modulo the call to normalise. Is that true?

The checking of the executable name can go, but the more important call is to normalise, as this gets the path into mixed mode, which means \ don't need to be escaped before being passed on to external utilities. Such as configure

It's failing at stage2, where SIMPLE_WIN_GETLIBDIR would be 1, so this means what you're getting back from getLibDir is likely not correct. I'm suspicious of the takeDirectory . takeDirectory part. Given our current layout <dir>/inplace/bin/ghc.exe taking a double takeDirectory would get you to <dir>/lib instead of <dir>/inplace/lib as we want. This would explain the error of not finding the settings file.

It's failing at stage2, where SIMPLE_WIN_GETLIBDIR would be 1, so this means what you're getting back from getLibDir is likely not correct. I'm suspicious of the takeDirectory . takeDirectory part. Given our current layout <dir>/inplace/bin/ghc.exe taking a double takeDirectory would get you to <dir>/lib instead of <dir>/inplace/lib as we want. This would explain the error of not finding the settings file.

Probably needs a guard for Hadrian or Makefile build. As the reloc hadrian Logic consistently only has bin and lib next to each other and no inplace anymore.

I did not, but it's quite simple: my code apparently isn't correct, causing build errors on (the Windows build of) harbormaster that I have not diagnosed yet. Shall I create a ticket to track the status of this patch?

It's failing at stage2, where SIMPLE_WIN_GETLIBDIR would be 1, so this means what you're getting back from getLibDir is likely not correct. I'm suspicious of the takeDirectory . takeDirectory part. Given our current layout <dir>/inplace/bin/ghc.exe taking a double takeDirectory would get you to <dir>/lib instead of <dir>/inplace/lib as we want. This would explain the error of not finding the settings file.

The takeDirectory . takeDirectory part was already there. I also just checked in ghci:

Probably needs a guard for Hadrian or Makefile build. As the reloc hadrian Logic consistently only has bin and lib next to each other and no inplace anymore.

Hmm. So in (your branch of) hadrian we have <build dir>/stage<n>/{bin, lib} while with the make build system we have ./inplace/{bin, lib} when building/running in place and... pretty much any structure we want when installing to some place on the system, except that in that case it's not a problem because we place the actual binaries in a fixed place and generate wrapper scripts that pass the right -B/path/to/libdir to GHC, in which case GHC doesn't have to look at some place relative to the path of the program (or symlink) through which it's invoked etc. So long story short, I don't think we need a different logic, I just have to find and fix one or more subtle issue(s) with my patch. Unless I'm missing something?