lambdacube3d / lambdacube-ir

LambdaCube 3D intermediate representation of 3D graphics pipelines. See:
https://lambdacube3d.wordpress.com/2013/10/12/introducing-the-lambdacube-intermediate-representation/
8 stars 3 forks source link

Building on Nix Fails (old dependencies/old haskell?) #8

Open dustinlacewell opened 3 years ago

dustinlacewell commented 3 years ago

Building on Nix currently fails due to old dependencies no longer tracked on Nixpkgs:

Configuring lambdacube-ir-0.3.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 Setup.hs:2:8 in main:Main
Setup: Encountered missing or private dependencies:
aeson >=0.9 && <0.12,
base >=4.8 && <4.10,
containers ==0.5.*,
vector ==0.11.*

builder for '/nix/store/znsy8jxgydi9z0gxzk9g5dnq5ys6p1br-lambdacube-ir-0.3.0.1.drv' failed with exit code 1

It looks like the packages aeson, base, containers and vector are too old to be built by Nix.

09:51 <foo> okay yeah that's quite old dependencies
09:51 <me> foo: I guess this error means that the lambdacube-ir package is "broken" in that it incorrectly specifies its dependences (or something?)
09:52 <foo> me: it adds dependency constraints which are incompatible with what we have in nixpkgs
09:52 <foo> we don't do constraint solving, but provide one standard version per package (following stackage usually)
09:52 <foo> this makes haskellPackages manageable, but also means we can't really build old, unmaintained packages without hassle

So using a certain shell.nix was able to force it to build anyway:

let
  pkgs = import <nixpkgs> { overlays = [(self: super:
    {
      haskellPackages = super.haskell.packages.ghc8107.extend (selfHS: superHS: {
          # custom git packages here
          lambdacube-ir = pkgs.haskell.lib.doJailbreak superHS.lambdacube-ir;
      });
    })];
  };
in
  (pkgs.haskellPackages.callCabal2nix "lcube" ./. {}).env.overrideAttrs (old: {
    buildInputs = old.buildInputs ++ [
      pkgs.ghostscript
      pkgs.entr
      pkgs.haskellPackages.ghcid
      pkgs.haskellPackages.ghcide
      pkgs.haskellPackages.haskell-language-server
      pkgs.haskellPackages.hlint
    ];
  })

But then it fails due to some error related to Semigroup:

Preprocessing library for lambdacube-ir-0.3.0.1..
Building library for lambdacube-ir-0.3.0.1..
[1 of 5] Compiling LambdaCube.Linear ( src/LambdaCube/Linear.hs, dist/build/LambdaCube/Linear.o, dist/build/LambdaCube/Linear.dyn_o )
[2 of 5] Compiling LambdaCube.IR    ( src/LambdaCube/IR.hs, dist/build/LambdaCube/IR.o, dist/build/LambdaCube/IR.dyn_o )
[3 of 5] Compiling LambdaCube.Mesh  ( src/LambdaCube/Mesh.hs, dist/build/LambdaCube/Mesh.o, dist/build/LambdaCube/Mesh.dyn_o )
[4 of 5] Compiling LambdaCube.PipelineSchema ( src/LambdaCube/PipelineSchema.hs, dist/build/LambdaCube/PipelineSchema.o, dist/build/LambdaCube/PipelineSchema.dyn_o )
[5 of 5] Compiling LambdaCube.PipelineSchemaUtil ( src/LambdaCube/PipelineSchemaUtil.hs, dist/build/LambdaCube/PipelineSchemaUtil.o, dist/build/LambdaCube/PipelineSchemaUtil.dyn_o )

src/LambdaCube/PipelineSchemaUtil.hs:17:10: error:
    • No instance for (Semigroup PipelineSchema)
        arising from the superclasses of an instance declaration
    • In the instance declaration for ‘Monoid PipelineSchema’
   |
17 | instance Monoid PipelineSchema where
   |          ^^^^^^^^^^^^^^^^^^^^^

builder for '/nix/store/3sj0pcch67chicsz9xss7630pczlnci9-lambdacube-ir-0.3.0.1.drv' failed with exit code 1
cannot build derivation '/nix/store/l0f2xjkzrq9yv2svywbflbmy3xg5f4d9-ghc-8.10.7-with-packages.drv': 1 dependencies couldn't be built
error: build of '/nix/store/l0f2xjkzrq9yv2svywbflbmy3xg5f4d9-ghc-8.10.7-with-packages.drv' failed

Is it that lambdacube is simply targetting too old of a Haskell?

csabahruska commented 3 years ago

Hi, I'm not a nix user. I use stack. Feel free to update the nix scripts. (the stack.yaml works, it can build the project)

dustinlacewell commented 3 years ago

I suppose the question is whether lambdacube will eventually see a modernization of its dependencies.

csabahruska commented 3 years ago

not now, but eventually sure.

ScottFreeCode commented 1 year ago

Hi @csabahruska,

The way NixPkgs handles Haskell, for packages on Hackage, is basically just that it builds the packages that are on Hackage. As long as it compiles, there shouldn't be anything else needed.

So, currently with version 0.3.0.1 on Hackage, all I have to patch to get it to compile is fixing the Monoid/Semigroup thing and loosen the version bounds… I figured out what changes to make for that, so I was going to put in a PR.

Turns out, the code on GitHub is already updated! It just hasn't been published to Hackage so NixPkgs isn't picking it up.

If it's possible to publish the latest version to Hackage, I believe that should resolve this!