| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to make the packages in this repo "reinstallable", we need to
associate source code with a specific packages. Having a top level
`/includes` dir that mixes concerns (which packages' includes?) gets in
the way of this.
To start, I have moved everything to `rts/`, which is mostly correct.
There are a few things however that really don't belong in the rts (like
the generated constants haskell type, `CodeGen.Platform.h`). Those
needed to be manually adjusted.
Things of note:
- No symlinking for sake of windows, so we hard-link at configure time.
- `CodeGen.Platform.h` no longer as `.hs` extension (in addition to
being moved to `compiler/`) so as not to confuse anyone, since it is
next to Haskell files.
- Blanket `-Iincludes` is gone in both build systems, include paths now
more strictly respect per-package dependencies.
- `deriveConstants` has been taught to not require a `--target-os` flag
when generating the platform-agnostic Haskell type. Make takes
advantage of this, but Hadrian has yet to.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The CODEOWNERS documentation has this to say on the current matching
behaviour:
> The path definition order is significant: the last pattern matching a
> given path is used to find the code owners.
Take this as an example:
/rts/ bgamari [...]
/rts/win32/ Phyx
(I'm omitting the '@' so as to not notification spam everyone)
This means a change in a file under win23 would only have Phyx but not
bgamari as approver. I don't think that's the behaviour we want.
Using "sections" we can get additive behaviour instead, from the docs:
> Additionally, the usual guidance that only the last pattern matching the
> file is applied is expanded such that the last pattern matching for each
> section is applied.
[RTS]
/rts/ bgamari [...]
[WinIO]
/rts/win32/ Phyx
So now since those entries are in different sections both would be added to
the approvers list.
The sections feature was introduced in Gitlab 13.2, see "Version history"
on [1] we're currently running 18.8 on gitlab.haskell.org, see [2].
[1]: https://docs.gitlab.com/13.8/ee/user/project/code_owners.html#code-owners-sections
[2]: https://gitlab.haskell.org/help
|
| | |
|
| |
|
|
| |
Update Haddock submodule
|
| | |
|
| |
|
|
|
|
|
| |
In !980 Richard noted that he could not approve the MR.
This mis-spelling was the reason.
[skip ci]
|
| |
|
|
|
|
| |
I suspect this is why @simonmar wasn't notified of !706.
[skip ci]
|
| | |
|
| | |
|
| |
|
|
| |
[skip ci]
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
| |
[skip ci]
|
| |
|
|
| |
[skip ci]
|
| | |
|
|
|
GitLab uses this file to suggest reviewers based upon the files that a Merge
Request touches.
[skip-ci]
|
