Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build with ghc(js) 9.8.2 + 9.10.1 #1093

Open
wants to merge 22 commits into
base: develop
Choose a base branch
from

Conversation

ymeister
Copy link
Collaborator

This PR mostly deals with building obelisk/lib libraries via ghc(js) 9.8.2 + 9.10.1, and not integrating new js backend into default.nix, yet. I intend to create a test app and based on that app recreate default.nix that uses haskell.nix instead of nixpkgs/reflex-platform (may backport some things into reflex-platform). Still, it passes selftest and is backwards compatible with previous ghc/ghcjs setup.

Built using haskell.nix/cabal-install.
Here's a "hello world" example on how to build a project depending on this version of obelisk: https://github.com/ymeister/obelisk-example

Needs:

I have:

  • Based work on latest develop branch
  • Followed the contribution guide
  • Looked for lint in my changes with hlint . (lint found code you did not write can be left alone)
  • Run the test suite: $(nix-build -A selftest --no-out-link)
  • Updated the changelog
  • (Optional) Run CI tests locally: nix-build release.nix -A build.x86_64-linux --no-out-link (or x86_64-darwin on macOS)

@@ -14,5 +14,5 @@ cabal.project.local
**/ghcid-output.txt

# HLS specific files
lib/cabal.project
#lib/cabal.project
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why a comment?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So that git wouldn't ignore lib/cabal.project for cabal/haskell.nix builds.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not remove then?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well somebody put it there for a reason I assume, if it causes problems in the future people would at least see a possible solution there.

@@ -39,6 +40,9 @@ library
-Wall -Werror -Wredundant-constraints -Wincomplete-uni-patterns -Wincomplete-record-updates -O2
-fno-warn-unused-do-bind -funbox-strict-fields -fprof-auto-calls

if arch(javascript)
buildable: False
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems right, but I'm confused on why we didn't need a if impl(ghcjs) before. Was it only implicitly gated by cabal.project ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure...

Comment on lines 1 to 32
index-state: 2024-08-04T00:00:00Z
allow-newer: all

constraints:
hnix-store-core < 0.7
, hnix-store-remote < 0.7

source-repository-package
type: git
location: https://github.com/ymeister/splitmix.git
tag: fe4d9e4ec01ba7caf8053d6888ec2e7f89fad874
--sha256: 19fbwcmdmb9w34cp19r2j4qywhnjmxxdv4rwci29pzbvgbnnjdia

if !arch(javascript)
source-repository-package
type: git
location: https://github.com/ymeister/hs-git.git
tag: 4534c4589fc63d76d4a28f4ca9d810bea021964b
--sha256: 12c4llylc5zls85x11inkxdwllbps77pvwyji7jv9a8c069fg6sf

source-repository-package
type: git
location: https://github.com/mpickering/haskell-filesystem.git
tag: 2eb26717e986442796d703a80869e6826a10191e
subdir: system-fileio system-filepath
--sha256: sha256-VDShV+gkVUooMy1OtxrFfZrTAVVhWN/Ffjd6Qq0kHNM=

source-repository-package
type: git
location: https://github.com/ymeister/unix-compat.git
tag: 339649401c876ca1f76c6f94d6b099c8c47fa9e2
--sha256: 0j85q0mqg929nlz9ks6jaxz54pkvifpmldsvqjcz4bv6wml8m3wd
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we still need these?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, for splitmix. "Probably yes" for the others.

@@ -0,0 +1,23 @@
if arch(javascript)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we pull the common ones out of the if ?
Also, should we remove the old cabal.project.dev ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we pull the common ones out of the if ?

Yes. Wasn't aware that there could be multiple packages: statements that collect all of them at the time of writing.

Also, should we remove the old cabal.project.dev ?

I assume so. Didn't want to touch that as I was not 100% of cabal.project.dev goal.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. Wasn't aware that there could be multiple packages: statements that collect all of them at the time of writing.

Me neither, I didn't even know we could use cabal conditionals in .project

I assume so. Didn't want to touch that as I was not 100% of cabal.project.dev goal.

I don't see it doing anything your cabal.project doesn't do and better.
I think it's bitrotted due to the bad ergonomics I ran into when doing the GHC 9.6 PR.
The libs had -Werror which was a pain for nix builds but the cabal.project was explicitly disabling that, contributing to the problem.

Comment on lines -29 to -33
( CliConfig
, CliLog
, CliThrow
, CliT (..)
, ProcessFailure
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huh, were these all just unused?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess?

"Make packages found in DIR available in the package database (but only when they are used dependencies). \
\ This will build the packages in DIR before loading GHCi. \
\See help for --interpret for how the two options are related."
"Make packages found in DIR available in the package database (but only when they are used dependencies). This will build the packages in DIR before loading GHCi. See help for --interpret for how the two options are related."
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we know why these lines were split that way before?
I don't particularly mind this change, but in general let's avoid doing unrelated drive-by changes in PRs as long as we have a big PR queue of potential conflicts

Copy link
Collaborator Author

@ymeister ymeister Jan 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think multi-line string thing broke or changed is some way in newer ghc versions. Couldn't compile without this change.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aaah it's some interaction of multiline strings with {-# LANGUAGE CPP #-}. I remember that biting me once.
I think there's actually a multiline string extension on 9.12 but we can't ditch older GHC yet so let's go with your change

@@ -66,6 +65,11 @@ import System.PosixCompat.User
import qualified System.Process as Proc
import Text.ShellEscape (sh, bash, bytes)

#if !MIN_VERSION_base(4,18,0)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason we're using base here but used __GLASGOW_HASKELL__ >= 906 above?
Maybe it'd be clearer if we used MIN_VERSION_mtl(2,3,0)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because the root of the error/warning is the change in the base library. Although ghc versions and base go hand-in-hand, I preferred addressing the root cause.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I thought this was the mtl re-export breakage in 2.3


unpackTextEncoder :: (Applicative check, Applicative parse, IsText text) => Encoder check parse text String
unpackTextEncoder = isoEncoder unpacked
unpackTextEncoder = viewEncoder unpacked
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Didn't I already do this in #1075?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this PR is built with parts of #1075 . I thought I cherry-picked the commits or at least marked you as a co-author, but apparently the commit history disagrees... You can force push necessary changes if you want or build a new PR using parts of this one if you want.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's fine either way, I just don't understand how github produces this diff when both develop and the PR branch have viewEncoder

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the diff is stuck at the old develop due to merge conflicts. Merging develop into this branch will probably resolve the issue.

@@ -24,7 +24,7 @@ library
, git
, github
, here
, hnix
, hnix >=0.5
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't see anything else in the command diff related to this.
For future reference, was this already de-facto or needed for some other reason?

@@ -24,6 +24,7 @@ library
, filepath
, template-haskell
, text
, th-abstraction >= 0.6
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

$ ob run -v
...
Configuring obelisk-asset-manifest-0.1...
CallStack (from HasCallStack):
  $, called at libraries/Cabal/Cabal/Distribution/Simple/Configure.hs:1024:20 in Cabal-3.2.1.0:Distribution.Simple.Configure
  configureFinalizedPackage, called at libraries/Cabal/Cabal/Distribution/Simple/Configure.hs:477:12 in Cabal-3.2.1.0:Distribution.Simple.Configure
  configure, called at libraries/Cabal/Cabal/Distribution/Simple.hs:625:20 in Cabal-3.2.1.0:Distribution.Simple
  confHook, called at libraries/Cabal/Cabal/Distribution/Simple/UserHooks.hs:65:5 in Cabal-3.2.1.0:Distribution.Simple.UserHooks
  configureAction, called at libraries/Cabal/Cabal/Distribution/Simple.hs:180:19 in Cabal-3.2.1.0:Distribution.Simple
  defaultMainHelper, called at libraries/Cabal/Cabal/Distribution/Simple.hs:116:27 in Cabal-3.2.1.0:Distribution.Simple
  defaultMain, called at /nix/store/4mdp8nhyfddh7bllbi7xszz7k9955n79-Setup.hs:2:8 in main:Main
Setup: Encountered missing or private dependencies:
th-abstraction >=0.6

Copy link
Collaborator

@alexfmpe alexfmpe Feb 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually this has already been handled in 0393bdf and bca0ad5

@@ -61,7 +61,7 @@ import System.IO.Temp
import System.IO.Unsafe (unsafePerformIO)
import System.PosixCompat.Files
import System.PosixCompat.Types
import System.PosixCompat.User
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I doubt we want to go out of our way to keep using an old version of unix-compat, for the sake of a single function which simply crashes: https://github.com/jacobstanley/unix-compat/pull/62/files#diff-93ed634b109420481984ea0fecc52a958c1d98c2728f8ec0b4c6ed741a8d4a24L55-L63

If ob survives long enough for windows support to be a concern, a lot of things will need to be revisited anyway.

type: git
location: https://github.com/mpickering/haskell-filesystem.git
tag: 2eb26717e986442796d703a80869e6826a10191e
subdir: system-fileio system-filepath
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure why this was added but the upstream PR has been merged fpco/haskell-filesystem#27

Comment on lines +239 to +241
#if MIN_VERSION_nix_thunk(0,7,1)
<*> optional (strOption (short 'r' <> long "rev" <> metavar "REVISION" <> help "Update to this specific revision"))
#endif
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I backported for now, but shouldn't we simply be importing all these parsers from nix-thunk?
@ryantrinkle

Comment on lines 96 to +104
Right (ThunkData_Packed _ ptr) -> return ptr
_ -> wrapNixThunkError (getThunkPtr CheckClean_NotIgnored root Nothing)
_ -> wrapNixThunkError $ compat $ getThunkPtr CheckClean_NotIgnored root Nothing
deployInit' thunkPtr deployOpts
where
#if MIN_VERSION_nix_thunk(0,7,1)
compat = fmap $ \(ptr, _isWorktree) -> ptr
#else
compat = id
#endif
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we should treat a worktree dir the same as a standalone unpacked dir?
@ryantrinkle

@alexfmpe alexfmpe force-pushed the ghc(js)-9.10 branch 5 times, most recently from a3e2aea to b97258d Compare February 1, 2025 15:59
@alexfmpe alexfmpe force-pushed the ghc(js)-9.10 branch 2 times, most recently from 965efc7 to 60b38d6 Compare February 1, 2025 17:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants