Multi-target support for GHC

[angerman]

GHC has been a single-target compiler for now. This has meant that we needed to compile a new compiler for each target; over time this becomes increasingly complicated, and annoying as we rebuild the same code multiple times. @hsyl20 has been working on lifting GHC defines, and other hard coded conditionals in GHC to be able to introduce a target selction flag to GHC, based on a separate settings file.

• -target was implemented in: fbdb38d
• Listing targets was implemented in: a9a88e5
• We can also get the target from the executable prefix: 814aadb, 8df59de, 14bbfb8, 66ee4f8

The easiest cross compiler is the JavaScript cross compiler for now (doesn't need extensive iserv logic).

• Build GHC.
• Symlink javascript-unknown-ghcjs-ghc to ghc executable.
• Test that javascript-unknown-ghcjs-ghc compiles Hello.hs properly.
• Try a more involved example that requires our cabal-install build, and using javascript-unknown-ghcjs-ghc-pkg, and javascript-unknown-ghcjs-ghc. There are bugs here, we probably need to teach ghc-pkg about -target (as well as the symlink logic as well, to find the proper settings).
• Discover all issues, catalogue them, and fix them.

EDIT: Generally we want to follow existing conventions of -. This will also make integration into cabal-install easier for now. Having an explicit -target flag is good to have though!
NOTE: We do want to get rid of the whole -B nonsense as well. Yes this will still be required for OSs that can't figure out the location of an executable, but for windows, linux, macos, and bsd the current logic where bin/ghc can figure out it's location and locate ../lib/settings, ... without an annoying wrapper script is the preferred way to go.

See #34 for the pull request that includes all the necessary commits (see above) from https://github.com/hsyl20/ghc/tree/hsyl20/multi-target.

[hsyl20]

I have a patch in https://github.com/hsyl20/ghc/tree/hsyl20/multi-target that adds support for a --target=foo flag.

Example:

# build ghc and boot libraries for javascript in _build/stage1_javascript
> emconfigure ...
> ./hadrian ...

# build ghc and boot libraries for native in _build/stage1
> ./configure
> ./hadrian

# install boot libraries and settings for javascript in native GHC's topdir
> mkdir -p _build/stage1/lib/targets/javascript/
> cp -r _build/stage1_javascript/lib _build/stage1/lib/targets/javascript

# now enjoy your on-demand cross-compiler
> _build/stage1/bin/ghc Hello.hs
[1 of 2] Compiling Main             ( Hello.hs, Hello.o )
[2 of 2] Linking Hello [Objects changed]
> file Hello
Hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 4.4.0, BuildID[sha1]=9527cdaecde3b24e1fddd357884eeae141351e5f, not stripped
> ./Hello
Hello

>  _build/stage1/bin/ghc --target=javascript Hello.hs
[1 of 2] Compiling Main             ( Hello.hs, Hello.o )
[2 of 2] Linking Hello.jsexe [Objects changed]
>  file Hello
Hello: Node.js script executable, ASCII text
>  ./Hello
Hello

[malteneuss]

Oh wow, i really appreciate this initiative. In terms of visibility it would be nice if you could mention the current state in https://discourse.haskell.org/, maybe even on the https://blog.haskell.org/, https://programming.dev/c/haskell and (yikes) https://www.reddit.com/r/haskell/. The Haskell ecosystem could benefit from more awareness.

[hsyl20]

There is nothing to announce yet really.

[hsyl20]

Alright so the GHC part works but as soon as we want to use it with cabal it breaks.

Say we have a wrapper script ghc-foo that calls ghc --target=foo and we use it with cabal -w ghc-foo.

Then cabal calls ghc-pkg which assumes a single global package database.

How does it find it? By calling the innocent looking ghc-boot:GHC.BaseDir.getBaseDir and appending some builtin package db path, even reading GHC's settings file to do it...

How does getBaseDir find the topdir of GHC? By looking at the executable path (here of ghc-pkg) and messing with it a bit.

Now we have the issue that ghc-pkg and ghc --target=foo don't have the same notion of what the global db is. Note that it would be exactly the same issue with ghc -Bwherever.

I guess the next natural step would to make ghc-pkg learn about the targets? Or to set an environment variable for it to find the base dir? Or to have one ghc-pkg program per target installed in the appropriate path and pass cabal --with-ghc-pkg=.../foo/bin/ghc-pkg...?

[If it was only me, I would replace these 3 tightly coupled programs (cabal, ghc, ghc-pkg) with a single one to simply not have to deal with this maddening accidental complexity that serves no real purpose.]