Improving the Hadrian user experience
With the Make build system there are three ways to configure a GHC build:
- easily override ~all options on the command line
- easily override ~all options in a simple key-value file (mk/build.mk)
- easily override ~all options with environment variables
This makes GHC usable to both developers (who desire the ability to easily reconfigure their tree on an ad-hoc basis) and packagers (who want the ability to change a few configuration options in an automated manner).
On the other hand, with Hadrian, we pass some options on the command-line, some options through the UserSettings module/mechanism (in particular by defining custom Flavours, for eveything that has to do with GHC options, build ways, etc), there's a little bit of env var sensitivity (e.g the TEST env var) too.
It is also pretty tricky to programmatically edit/generate UserSettings.hs, so even if we could customize everything we want there (we can't, e.g all the things that we can tweak on the command-line that don't have a Flavour/UserSettings.hs equivalent, like --freze1 or all the --test-* CLI options), that would not be a satisfactory solution for many GHC developers. A particular "subproblem" is the lack of a solution to always pass some options to Hadrian itself! See #15890, that this ticket supersedes.
Hadrian as it is today therefore seems to suffer from a few issues:
- it's hard for packagers to use and pretty much requires that they know Haskell "well enough"
- it's hard for developers to change the build configuration in one-off ways (see e.g #16267 (closed))
- configuration is scattered in a few places (command line options, user settings (incl. flavour), environment variables)
- configuration is hard to discover
All in all, this makes me think we want a more uniform solution for customizing build configurations, which Hadrian's Args DSL + UserSettings/Flavour mechanism doesn't offer. It can stay around but doesn't seem like the best we can offer to users in terms of UI, for the reasons outlined above. A reasonable UI might be a key=value style syntax, as GHC devs and packagers from all backgrounds would quite likely find it familiar, and that would make builds easily configurable from the command-line, the environment and files (à la build.mk), therefore bringing Hadrian to a point where it could finally support 1., 2. and 3. from the beginning of this ticket.