hawk
hawk copied to clipboard
gelisam
don't use the GHC from the PATH
the ghc when hawk is installed might not be the same as the ghc which is in the PATH when hawk is called. is there a way to capture ghc's installation path at compile-time so that it is used at runtime as well? if not, we should probably add a way to configure hawk to use a user-specified ghc. Few users are still going to have ghc-8.4.4 as their main ghc!
What do you feel about using the same solution here as the one discussed in #252 for retrieving the package database: just ask the user to supply an environment variable. This is e.g. the approach I used to get stuff working with Nix in https://github.com/gelisam/hawk/compare/main...masaeedu:bypass_package_db_detection.
I would much prefer if hawk just worked out of the box! As a nix user, I'm sure you're used to jumping through a lot of hoops in order to get software working and so setting one more environment variable is no big deal ;) But for me, I think my software should try to detect the right configuration, and only ask for help if it's stuck.
As for the issue itself, I have a few ideas:
- close the ticket since hawk is no longer relying on an outdated version of ghc
- since the current ghc version is likely to match when hawk is first installed (but diverges over time as the user installs new versions of ghc but doesn't necessarily recompile hawk with that version), save the path to the first ghc used in
~/.hawk - that's probably one true when cabal is used but not for stack, so some more installation-method magic might be needed
- alternatively, save the ghc version at compile time (that should be accessible via a CPP variable), detect at runtime if the ghc in the PATH matches the version used at compile time, and only if it doesn't match do we give up and explain what the problem is and how to set the path to ghc using an environment variable.
...or we could just not call ghc at runtime :)
as #126 explains, we're calling ghc in order to compile the Hawk Prelude, and we're doing that in order to improve performance by using the compiled version of that code instead of the interpreted version, but it doesn't seem like that's actually working.