Minimum Viable Product for tree-tremble
snowleopard opened this issue · comments
After a Hadrian's-Wall-long discussion in #232, it looks that it will be best to postpone the Great Merge (the tree-tremble milestone) until Hadrian meets the Minimum Viable Product requirements.
Let us agree on what this MVP is. The current list includes the following (I will keep updating it as we go):
- Binary and source distributions, #219. Estimated effort: 2-5 weeks (I don't know much about this).
- Implement
dynamicway, #4. Estimated effort: 1-2 weeks. - Support most standard build flavours, #188, #268. Estimated effort: 1 week.
- Cross-compilation, #177. Estimated effort: 3-5 weeks (I don't know much about this).
Please let me know if the above list needs any changes.
The list of current limitations is here: https://github.com/snowleopard/hadrian#current-limitations.
Note, the above effort estimates are based on my abilities and availability. I'm sure other people could do it faster, and if they volunteer to help I will amend the estimates.
Items removed from the list:
- I would add cross-compilation to the list (probably not hugely difficult, but if it shows up weaknesses in the overall architecture you'll want to get them addressed before the merge).
- I would remove the documentation requirement. The overall "principles" are covered in the paper we wrote. The details are covered in the code. I'm sure additional docs will help everyone, but having them produced on-demand even after merging seems fine. The old system required docs precisely because it wasn't compositional, the new one is just a bunch of disjointed stuff, none of which is too confusing in isolation.
@ndmitchell Thanks, I agree. I've amended the list.
This goes very slowly, but now we've got source distribution rules, #219.
Posting here as requested on ghc-devs: A really useful feature of the build system today is that I can make 2 in the ghc subdirectory and get a very fast rebuild. In particular, no dependency-checking is done (which takes several seconds). I would be quite disappointed to see this (admittedly unsafe) feature be dropped.
It is also convenient to tell the build system to target just one specific file (e.g., libraries/base/dist-build/.../Data/Type/Equality.o), which I've done when building that file with stage-1 fails and I'm debugging stage-1. I could probably live without this feature though.
Thanks @goldfirere!
Freezing Stage1 is a popular feature and has already been requested -- see #250. We will provide an equivalent in Hadrian.
Rebuilding a single file is already possible by specifying its name as the build target, i.e. hadrian target, but at the moment this will also trigger rebuilds in Stage1.
This isn't just about freezing stage 1. It's about re-building just the compiler (no libraries) and skipping the time-consuming dependency analysis.
@goldfirere I see, thanks. If I understand correctly, the freeze feature should be flexible enough to freeze different sets of build artefacts: whole stages, packages, etc.
One simple way to support such custom freezing is via predicates, e.g. having a user setting freeze:
freeze :: Predicate
freeze = return False -- default setting: freeze nothing
freezeStage1 :: Predicate
freezeStage1 = stage0 -- freeze all artefacts built by the bootstrapping (Stage0) compiler
freezeAllButCompiler :: Predicate
freezeAllButCompiler = not <$> package compiler -- freeze all packages expect compilerThese predicates can be composed as explained here:
https://github.com/snowleopard/hadrian/blob/master/doc/user-settings.md#verbose-command-lines
make 2 is a combination of freezing stage 1 for the duration of this build and building a single target (the compiler). @snowleopard we need to be able to specify what to freeze from the command line, in addition to having a user setting.
@simonmar How critical is the ability to specify such settings via the command line? Isn't the ability to select a user build flavour from the command line sufficient?
Hadrian has been merged, so I think we can close this issue.