On 2019-03-15 at 13:28:21 -0400, Ben Gamari wrote: [...]
We should keep in mind that users and packagers, not GHC developers, are the primary audience of GHC's build system. For their sake we should strive to keep GHC's build system as close to the usual configure/make/make install workflow as possible.
Actually, even as a GHC developer, I strongly prefer the IMO quite intuitive configure/make phase-separated workflow I've been used to for over 2 decades. It's deeply ingrained into my muscle memory and my tooling automatically knows what to do when it discovers a `configure` script and/or a `GNUmakefile`/`Makefile` file in the filesystem and I'm not excited to have to adapt all my dev scripts/integrations to make them Hadrian-aware which is effectively a bespoken build-system used by exactly one project and starting with a specific version of the project while the previous ones still require Makefiles.
In fact, I have at times wondered whether when we switch to Hadrian as our primary build system we should ship our source distributions with a stub makefile to build and run hadrian, allowing downstreams to treat the distribution as a normal autotools-based package.
Definitely, I've been wanting this as well! It's perfectly fine IMO to
have it be a best-effort leaky abstraction. It'd be great if the
following standard invocations kept working, which represents the usage
pattern I use both in packaging scripts as well as in my dev-workflow
scripts.
The less I have to be aware of Hadrian pulling the strings behind the
curtains for my 80% use-cases the better. And if I need to do something
from the remaining 20% of use-cases that's when I'd be willing to invoke
Hadrian directly, as that's also when I'd be doing something
non-standard/non-routine anyway and I'd be consciously paying attention
anyway...
,----
| # an example build.mk with some of the keys I typically set one way or
| # another; just support a flat simple key/value grammar as text-file
| # config input to Hadrian
|
| cat > mk/build.mk <