haskellPackages.ghcjs-dom: build on js backend of ghc 9.8

[alexfmpe]

Description of changes

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[alexfmpe]

I assume on 9.6 the FFI support wasn't there yet as the build fails with

Preprocessing library for ghcjs-base-0.8.0.0..
Building library for ghcjs-base-0.8.0.0..
[ 1 of 73] Compiling Data.JSString.Internal ( Data/JSString/Internal.hs, dist/build/Data/JSString/Internal.o )
[ 2 of 73] Compiling Data.JSString.Internal.Fusion.Types ( Data/JSString/Internal/Fusion/Types.hs, dist/build/Data/JSString/Internal/Fusion/Types.o )
[ 3 of 73] Compiling Data.JSString.Internal.Fusion.CaseMapping ( Data/JSString/Internal/Fusion/CaseMapping.hs, dist/build/Data/JSString/Internal/Fusion/CaseMapping.o )
[ 4 of 73] Compiling Data.JSString.Internal.Fusion.Common ( Data/JSString/Internal/Fusion/Common.hs, dist/build/Data/JSString/Internal/Fusion/Common.o )
[ 5 of 73] Compiling GHCJS.Concurrent ( GHCJS/Concurrent.hs, dist/build/GHCJS/Concurrent.o )

GHCJS/Concurrent.hs:37:1: error:
    Could not find module ‘GHC.JS.Foreign.Callback’
    Use -v (or `:set -v` in ghci) to see a list of the files searched for.
   |
37 | import           GHC.JS.Foreign.Callback (OnBlocked(..))
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[ 6 of 73] Compiling GHCJS.Internal.Types ( GHCJS/Internal/Types.hs, dist/build/GHCJS/Internal/Types.o )

GHCJS/Internal/Types.hs:17:1: error:
    Could not find module ‘GHC.JS.Foreign.Callback’
    Use -v (or `:set -v` in ghci) to see a list of the files searched for.
   |
17 | import GHC.JS.Foreign.Callback (Callback)
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[25 of 73] Compiling JavaScript.Cast  ( JavaScript/Cast.hs, dist/build/JavaScript/Cast.o )
[32 of 73] Compiling JavaScript.Number ( JavaScript/Number.hs, dist/build/JavaScript/Number.o )

[alexfmpe]

I tried to add this before, alongside the other platformConfigurations, but the overrides would get lost as configuration-ghc-9.8.nix (passed in compilerConfig) would then reset to null or overwrite due to picking the most-recent hackage version.

[maralorn]

That’s unfortunate.

[maralorn]

I don’t get it. there do not seem to be conflicting overrides for the packages in ghcjs-9.x.nix after the changes you are making. Are you sure this doesn’t work?

[alexfmpe]

Are you sure this doesn’t work?

Confirmed to be working now. I think the problem is that I originally had

    aeson = disableLibraryProfiling super.aeson;

which was being replaced by the flat aeson override in the 9.8 bit but now we disable profiling globally for JS flavors so this is no longer a problem.

[sternenseemann]

8c61a34 should simplify this PR a lot! I'm wondering if we even need a special file for the js backend at all. Most of these packages wouldn't build with normal GHCs anyways, so we can apply the overrides in the normal configuration-nix.nix? Or do you think there's an advantage in having them conditional? The disadvantage of this is that eval regressions won't be caught since we can't test the entire set on Hydra…

[alexfmpe]

8c61a34 should simplify this PR a lot!

Huh, how? DId you mean the addBuildDepends self.ghcjs-base shouldn't be needed anymore?
Looking at that diff it doesn't seem hackage-packages.nix changed anything in the dependent packages generation.

With this change, the ghcjs-base = super.ghcjs-base_0_8_0_0; override fails but if I remove it I get

$ nix-build -A pkgsCross.ghcjs.haskell.packages.ghc98.ghcjs-base                                                                                                                        
error:
(...)
           12|   (self: super: {
           13|     ghcjs-base = addBuildDepends (with self; [
             |     ^
           14|       aeson

       (stack trace truncated; use '--show-trace' to show the full trace)
       error: value is null while a set was expected

I think the change also requires removing

nixpkgs/pkgs/development/haskell-modules/configuration-common.nix

Line 270 in 8c61a34

ghcjs-base = null;

so that it builds on pkgsCross.ghcjs.

That in turn makes nix-build -A haskell.packages.ghc98.ghcjs-base switch from

error: expression does not evaluate to a derivation (or a set or list of those)

to

(...)
Running phase: buildPhase
Building ghcjs-base-0.8.0.0...
Running phase: checkPhase
Package has no test suites.
Running phase: haddockPhase
Warning: No documentation was generated as this package does not contain a
library. Perhaps you want to use the --executables, --tests, --benchmarks or
--foreign-libraries flags.
Running phase: installPhase
Error: Setup: No executables and no library found. Nothing to do.

error: builder for '/nix/store/nw2fyq4r6vv34nv8jlf9g3dvrkh5i0yv-ghcjs-base-0.8.0.0.drv' failed with exit code 1;
       last 10 log lines:

so we probably should set its supported platforms, but that needs the call2nix release.

Edit: Done

[alexfmpe]

Anything left to do here?

[maralorn]

Thank you very much!

Any explanation regarding the white space changes in hackage-packages.nix?

I left one other comment. Apart from that this looks good to me.

Ah, do we already have enough hydra jobs for this?

[sternenseemann]

I'd prefer if we could just use platformConfigurations for this instead.

[alexfmpe]

Agreed. This now works, as per: #309650 (comment)

[alexfmpe]

Any explanation regarding the white space changes in hackage-packages.nix?

Oops, fixed.
My editor automatically trimmed the trailing whitespace after I manually edited the file to handle a conflict with #316272

[sternenseemann]

Ah, do we already have enough hydra jobs for this?

Probably not, we should expand that, but that can probably be done in a follow up change.