Sylvain Henry authored 2 years ago and Marge Bot committed 2 years ago

`libiserv` serves no purpose. As it depends on `ghci` and doesn't have
more dependencies than the `ghci` package, its code could live in the
`ghci` package too.

This commit also moves most of the code from the `iserv` program into
the `ghci` package as well so that it can be reused. This is especially
useful for the implementation of TH for the JS backend (#22261, !9779).

Ben Gamari authored 2 years ago and Marge Bot committed 2 years ago

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.

John Ericson authored 3 years ago and Marge Bot committed 3 years ago

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.

Daniel Gröber (dxld) authored 4 years ago and Marge Bot committed 4 years ago

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

Sylvain Henry authored 4 years ago and Marge Bot committed 4 years ago

Update Haddock submodule

Ben Gamari authored 5 years ago and Marge Bot committed 5 years ago

In !980 Richard noted that he could not approve the MR.
This mis-spelling was the reason.

[skip ci]

Ben Gamari authored 5 years ago and Marge Bot committed 5 years ago

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]