I don't mind having a Hadrian interface for ./boot && ./configure but it seems that its current incarnation is too fragile. We could make it invoke those scripts directly or display a message telling the user to use ./boot && ./configure instead?
It's been working very well for me with Nix. With the caveat that I haven't done any GHC work for a few months, so I can't speak to the latest version.
It's infinitely preferable to me to the boot/configure cycle. I feel that hadrian -c is essential to my mental well being, as someone who doesn't work with GHC on a daily basis.
It's infinitely preferable to me to the boot/configure cycle. I feel that hadrian -c is essential to my mental well being, as someone who doesn't work with GHC on a daily basis.
Arnaud, how can we improve the ./boot; ./configure workflow to make it less taxing? Having to run configure periodically is a pretty common step in build instructions for FOSS projects, but if there is something that we can do to make it less painful we would certainly be willing to do so.
Maybe having a single (autocompletable) command would be better. But I think this misses the mark. The only thing that would really solve the configure workflow for me is for hadrian -c to work.
As I'm growing older and grumpier (as one does), I'm losing patience for build instructions of more than one command.
While it is true that ./configure is still fairly standard, I want to point out that modern tooling is steering clearly away for such additional step (which only exists, to begin with, to compensate for Make's limitations). I haven't typed ./configure in years (and it does make me happy (it also makes lucky: there are a lot of projects with a configure step still, as you rightly point out)).
I also find that ./boot is weird, and I think that one needs to run it quite often? I don't really remember since hadrian -c has saved me from thinking about it.
I understand the impetus to remove it (@Kleidukos 's point just below seems to summarize the problem quite well). But it still makes me quite grumpy (I predict audibly so, and I apologize in advance to anyone who works next to me).
I fully agree that ./boot needs to die, it's just stupid. And with hadrian we don't need most of it anyway.
What it effectively does is this:
Try to verify you have all submodules checked out. I'm fairly fine with builds just failing for people who fail to properly check out the repository. It's their fail, they need to learn.
It creates a bunch of Make support files all over the tree. Again we are trying to fix up some Make shortcomings, we don't need that with hadrian. In fact boot has a --hadrian flag, that simply skips this step.
it re-runs autoreconf, this is arguably stupid, but kindof in line with babysitting users, and papering over autoconf defects.
And another check (with we skip with --hadrian) to validate some make files.
So, we can completely elimiate boot, if we assume people don't need handholding, having submodules checked out properly and running autoreconf if they need to for a package. (That is usually just the case if you local autotools don't match with what we have ghc configured against).
Now configure is something very different. It does some discovery of the local system (sizes of types, ...), and has support for cross system detection and configuration. We can argue that in todays world configure is way too powerful, systems are just not that diverse anymore and figuring out which system libraries provide which functionality and need which headers, ..., can mostly be known beforehand.
It appears to me however that the usecase here is "I just want a command that build ghc for me". Again for that very singular usecase we could have a build.sh script that simply runs configure + hadrian. I fully understand that that there is no use for any of the configure or hadrian flags if you never use them.
Now once ghc is multi-target, we'll probably be able to scrap most of configure.
I understand we want hadrian to be the ultimate build tool, but we haven't even managed to kill make yet. Again the whole complexity that is introduced into hadrian just to try and get configure to run somehow, is absolutely bonkers.
So I'd like to see the following:
drop -c from hadrian, it should have never existed in the first place, and it keeps ending up in more and more tutorials, which is just simply bad.
kill make
drop boot
see what we can do about configure. What do we really need from it today? And what can we sensibly move into hadrian. This however is only feasable once we have killed make, otherweise we'll need to deal with hadrian and make at the same time, which is just complete madness and has been dragging us down for a long time already!
Indeed we could drop boot, especially once the make build system is finally dropped. I am quite supportive of this direction of travel. I also think it would be great if we could make configure's role as small as possible. For instance, I see no reason why its templating logic should be generating anything more than hadrian/cfg/system.cfg).
Finally, I agree with @angerman that configure will likely need to be replaced once GHC is runtime-retargetable. However, do note that I said "replaced"; just because GHC is runtime retargetable doesn't eliminate the need for configuration and the user will still need some way to tell the build system where it can find its bootstrap toolchain. The details on how this will look are still quite hazy; see #19877 (closed) for a few thoughts on this from @hsyl20 and me.
@aspiwack Yes, it has served me well for many months until literally this morning. I too would benefit greatly from keeping it, it's just that its current incarnation can't seem to live up to the expectations we put on its shoulders (namely: having the same behaviour as running ./boot && ./configure)
I’ve been saying this since the early days of hadrian. -c is simply wrong in hadrian. Hadrian is supposed to replace make. Not the whole build process.
It’s mixing phases now. Namely the configure and build phase. It adds a ton of stupid complexity to hadrian (to feed forward potential dependencies that would require running configure again). It completely hides the configure interface and everything needs to passed through hadrian now.
It’s just an utter miss feature.
If we want a simple command for people not working on ghc every day. Let’s have a build.sh that does boot + configure + hadrian. It’s still wrong imo just not as wrong as in hadrian.
If we want to nuke autotools because autotools suck, that’s a valid argument but that is also a different topic than replacing the build system (make) with hadrian.
I’m all for killing hadrian -c and have been so for many years now. Historical tidbit: it used to even be the default which was utterly insane as it kept rerunning configure unless explicitly told not to.
FWIW, I agree that incorporating configure into Hadrian is a bit odd and is very much a double-edged sword. Yes, it's convenient, but configure is intended to compute configuration and consequently isn't in general a hands-off process. Hadrian's configure support gives the illusion that configure is something that the user doesn't need to worry about, which seems like the wrong message to be sending. Moreover, as @angerman says, it introduces a great deal of complexity, and associated fragility.
If we want a simple command for people not working on ghc every day. Let’s have a build.sh that does boot + configure + hadrian. It’s still wrong imo just not as wrong as in hadrian.
The good thing of having -c is that Hadrian checks if configure needs to be executed or not. Configure shouldn't be used to perform substitutions as it is conflating too roles: being slow fetching configuration stuff and performing substitution in files. The latter should be done by Hadrian. That's what !5732 (closed) does but it's "blocked" on the removal of the old build system (I don't want to waste time modifying makefiles).