build-system design document: how relevant is it now?
I'm trawling the GHC wiki looking for things that will help me understand how the build system works and what might need to change for cross-compilation. I stumbled across https://gitlab.haskell.org/ghc/ghc/-/wikis/design/build-system which git helpfully tells me dates from 2008. I assume that none of it is relevant any longer. In its current form, the page seems only likely to confuse future contributors. I'd rather not leave things that way. Does the page have archival value? Is there a directory of legacy pages to which I should move it? Or shall I just delete the current text and replace it with a short note? Or what? Norman
It's already a sub-tree of "attic" -- ie out of date, retained for archive.
The title index is useful:
https://gitlab.haskell.org/ghc/ghc/-/wikis/index
Maybe "attic" isn't the best name. Maybe each page should have a header saying "Historical value only". But I hate the idea of outright deletion!
Simon
PS: I am leaving Microsoft at the end of November 2021, at which point simonpj@microsoft.com will cease to work. Use simon.peytonjones@gmail.com instead. (For now, it just forwards to simonpj@microsoft.com.)
| -----Original Message-----
| From: ghc-devs
Norman Ramsey
I'm trawling the GHC wiki looking for things that will help me understand how the build system works and what might need to change for cross-compilation. I stumbled across https://gitlab.haskell.org/ghc/ghc/-/wikis/design/build-system which git helpfully tells me dates from 2008. I assume that none of it is relevant any longer.
Somewhat surprisingly, the document is still largely accurate. However, I suspect that it is redundant given the rather significant body of build system documentation in the Wiki's Commentary. Ultimately all of this build system documentation will hopefully be obsoleted with the removal of the make build system in favor of Hadrian. It's hard to know what to do in cases like this. There is likely still archival value in this documentation but as archival documentation accrues the signal-to-noise ratio of the entire body of documentation falls. I am hope that we can avoid this in the future by erring towards keeping documentation in the repository, where it is easier to ensure that documentation tracks changes in the implementation that it describes. Cheers, - Ben
participants (3)
-
Ben Gamari -
Norman Ramsey -
Simon Peyton Jones