Build with ghc-9.2.1 #366

2022-01-25T18:34:36+01:00

mxxun commented

2022-01-25 18:34:36 +01:00

(Migrated from github.com)

Early-stage PR, to check whether this kind of copious CPP is agreeable, and to share partial results if those are useful.

My intention here is to build with 9.0.* and 9.2.* series both, as 9.0.3 might well have breaking changes, and in this case haskell language server's brittany plugin will want a ghc-9.0.3-compatible brittany.

(Possibly brittany should have 0.14.* series dedicated to ghc-9.0.*, and a separate 0.15.* series for ghc-9.2.* support?)

Early-stage PR, to check whether this kind of copious CPP is agreeable, and to share partial results if those are useful. My intention here is to build with 9.0.\* and 9.2.\* series both, as 9.0.3 might well have breaking changes, and in this case haskell language server's brittany plugin will want a ghc-9.0.3-compatible brittany. (Possibly brittany should have 0.14.* series dedicated to ghc-9.0.\*, and a separate 0.15.\* series for ghc-9.2.\* support?)

tfausak commented

2022-01-25 19:34:46 +01:00

(Migrated from github.com)

Wow, awesome work!

I would prefer to support only one major version of GHC at a time. Honestly that's really all I have the bandwidth to do. It's unfortunate that doing that makes things worse for HLS. I like your suggestion of maintaining separate versions for different versions of GHC. For instance 0.13.x supports GHC 8.10, 0.14.x supports 9.0, and 0.15.x could support 9.2.

I'm not sure how practical it is for Brittany, but separate conditionally-included modules are more palatable to me than CPP. For example my Splint project has different modules for GHC <= 8.8, 8.10, and >= 9.0: f06756e738/splint.cabal (L48)

Wow, awesome work! I would prefer to support only one major version of GHC at a time. Honestly that's really all I have the bandwidth to do. It's unfortunate that doing that makes things worse for HLS. I like your suggestion of maintaining separate versions for different versions of GHC. For instance 0.13.x supports GHC 8.10, 0.14.x supports 9.0, and 0.15.x could support 9.2. I'm not sure how practical it is for Brittany, but separate conditionally-included modules are more palatable to me than CPP. For example my Splint project has different modules for GHC <= 8.8, 8.10, and >= 9.0: https://github.com/tfausak/splint/blob/f06756e738813f9a8112237a217f57d5bc588eaa/splint.cabal#L48

mxxun commented

2022-01-25 21:24:18 +01:00

(Migrated from github.com)

Aha; what do you think of putting a ghc-9.0.x branch onto the current master tip, dedicating master onward to ghc-9.2.1, and patching the 9.0.x branch if and when that becomes a problem? This way there'd be no overhead due to CPP or massive duplication, at the possibly-small cost of no updates/backports on the older branch.

Aha; what do you think of putting a `ghc-9.0.x` branch onto the current master tip, dedicating master onward to ghc-9.2.1, and patching the 9.0.x branch if and when that becomes a problem? This way there'd be no overhead due to CPP or massive duplication, at the possibly-small cost of no updates/backports on the older branch.

tfausak commented

2022-01-26 15:50:41 +01:00

(Migrated from github.com)

That sounds reasonable to me.

pepeiborra commented

2022-05-04 20:44:28 +02:00

(Migrated from github.com)

I would prefer to support only one major version of GHC at a time. Honestly that's really all I have the bandwidth to do. It's unfortunate that doing that makes things worse for HLS.

The solution to this conundrum is probaby: migrate to ghc-lib-parser-9.2, which is guaranteed to build with ghc 8.10, 9.0, 9.2 and most probably will carry on to 9.4 and a few more major versions of ghc.

The best part is that you don't need to do much other than replacing the ghc dependency with a ghc-lib-parser dependency.

> I would prefer to support only one major version of GHC at a time. Honestly that's really all I have the bandwidth to do. It's unfortunate that doing that makes things worse for HLS. The solution to this conundrum is probaby: migrate to `ghc-lib-parser-9.2`, which is guaranteed to build with `ghc 8.10`, `9.0`, `9.2` and most probably will carry on to `9.4` and a few more major versions of `ghc`. The best part is that you don't need to do much other than replacing the `ghc` dependency with a `ghc-lib-parser` dependency.

👍 1

sergv commented

2022-07-13 23:20:10 +02:00

(Migrated from github.com)

The solution to this conundrum is probaby: migrate to ghc-lib-parser-9.2

Just a note regarding this migration: brittany heavily relies on ghc-exactprint which doesn't depend on ghc-lib-parser yet. Haven't researched whether there are plans to do so (seems reasonable that it could happen at some point though). If ghc-exactprint migrates then for brittany it would be easy to migrate indeed.

> The solution to this conundrum is probaby: migrate to ghc-lib-parser-9.2 Just a note regarding this migration: brittany heavily relies on `ghc-exactprint` which doesn't depend on `ghc-lib-parser` yet. Haven't researched whether there are plans to do so (seems reasonable that it could happen at some point though). If `ghc-exactprint` migrates then for brittany it would be easy to migrate indeed.

PiDelport commented

2022-10-29 11:33:03 +02:00

(Migrated from github.com)

Relevant ghc-exactprint issue:

https://github.com/alanz/ghc-exactprint/issues/93

The consensus seems to be that ghc-exactprint would need to be split up more before migrating to ghc-lib; see: https://github.com/alanz/ghc-exactprint/issues/93#issuecomment-867167997

Relevant `ghc-exactprint` issue: - https://github.com/alanz/ghc-exactprint/issues/93 The consensus seems to be that `ghc-exactprint` would need to be split up more before migrating to `ghc-lib`; see: https://github.com/alanz/ghc-exactprint/issues/93#issuecomment-867167997

This pull request can be merged automatically.

You are not authorized to merge this pull request.

You can also view command line instructions.

Step 1:

From your project repository, check out a new branch and test the changes.

git checkout -b mxxun/ghc-9.2 master

git pull origin mxxun/ghc-9.2

Step 2:

Merge the changes and update on Gitea.

git checkout master

git merge --no-ff mxxun/ghc-9.2

git push origin master

Sign in to join this conversation.

No reviewers

No Milestone

No project

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: hexagoxel/brittany#366