In reply to @alexfmpe:matrix.org
hackage.nix lets you take cabal.project into account, and also use the solver, but it's an entirely different beast

getting a duplicate symbol '_hourglass_clock_calendar' in: error when linking, but only on mac (or maybe it's a clang thing)
I'm assuming it's because this fork of a vincent package defines the same C function?

https://github.com/vincenthz/hs-hourglass/blob/master/cbits/unix.c#L16
https://github.com/mpilgrem/time-hourglass/blob/main/cbits/unix.c

In reply to @alexfmpe:matrix.org
if so, should we, I dunno, patch the vincent package to rename the symbol?

Yes, building with Hugs is currently the preferred way because it does not depend on any pre-generated code.
The stage 1 build uses a pre-existing mhs (usually runhugs wrapped mhs) with make.
The stage 2 build uses the stage 1 mhs with mcabal.

It's not immediately obvious to me how exactly mhseval.js is generated, but is there any reason you can't generate it using the stage 1 or stage 2 compiler?

I was trying to get it to work via

mhseval = pkgs.haskell.compiler.microhs.overrideAttrs (prevAttrs: {
  microhs-stage1 = prevAttrs.passthru.microhs-stage1.overrideAttrs {
    nativeBuildInputs = [ pkgs.breakpointHook ];
    postBuild = ''
      make bin/mhseval
    '';
    postInstall = ''
      cp bin/mhseval $out/bin/mhseval
    '';
  };
});

and didn't manage to get a useful output that way, I did try to copy it from stage1 to stage2 later, but I've changed a bunch of code around this