| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
| |
Currently it is only used by the make build system, which is soon to be
retired, and it has not built since 41cf758b. We may need to reintroduce
it when dynamic-linking support is introduced on Windows, but we will
cross that bridge once we get there.
Fixes #21753.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
