Cabal: With `build-type: Custom` and no `custom-setup`, there is an implicit dependency on very old Cabal, resulting in a cryptic error when trying to build.

Created on 26 Sep 2020  Â·  9Comments  Â·  Source: haskell/cabal

Describe the bug
With build-type: Custom and no custom-setup, there is an implicit dependency on very old Cabal, resulting in a cryptic error when trying to build.

See:

% cabal-1d320e8a5 build
Resolving dependencies...
cabal-1d320e8a5: Could not resolve dependencies:
[__0] trying: GLFW-0.5.2.5 (user goal)
[__1] next goal: GLFW:setup.Cabal (dependency of GLFW)
[__1] rejecting: GLFW:setup.Cabal-3.2.0.0/installed-3.2.0.0 (conflict: GLFW =>
GLFW:setup.Cabal>=1.11 && <1.25)
[__1] skipping: GLFW:setup.Cabal-3.2.0.0, GLFW:setup.Cabal-3.0.2.0,
GLFW:setup.Cabal-3.0.1.0, GLFW:setup.Cabal-3.0.0.0, GLFW:setup.Cabal-2.4.1.0,
GLFW:setup.Cabal-2.4.0.1, GLFW:setup.Cabal-2.4.0.0, GLFW:setup.Cabal-2.2.0.1,
GLFW:setup.Cabal-2.2.0.0, GLFW:setup.Cabal-2.0.1.1, GLFW:setup.Cabal-2.0.1.0,
GLFW:setup.Cabal-2.0.0.2 (has the same characteristics that caused the
previous version to fail: excluded by constraint '>=1.11 && <1.25' from
'GLFW')
[__1] rejecting: GLFW:setup.Cabal-1.24.2.0, GLFW:setup.Cabal-1.24.0.0,
GLFW:setup.Cabal-1.22.8.0, GLFW:setup.Cabal-1.22.7.0,
GLFW:setup.Cabal-1.22.6.0, GLFW:setup.Cabal-1.22.5.0,
GLFW:setup.Cabal-1.22.4.0, GLFW:setup.Cabal-1.22.3.0,
GLFW:setup.Cabal-1.22.2.0, GLFW:setup.Cabal-1.22.1.1,
GLFW:setup.Cabal-1.22.1.0, GLFW:setup.Cabal-1.22.0.0,
GLFW:setup.Cabal-1.20.0.4, GLFW:setup.Cabal-1.20.0.3,
GLFW:setup.Cabal-1.20.0.2, GLFW:setup.Cabal-1.20.0.1,
GLFW:setup.Cabal-1.20.0.0, GLFW:setup.Cabal-1.18.1.7,
GLFW:setup.Cabal-1.18.1.6, GLFW:setup.Cabal-1.18.1.5,
GLFW:setup.Cabal-1.18.1.4, GLFW:setup.Cabal-1.18.1.3,
GLFW:setup.Cabal-1.18.1.2, GLFW:setup.Cabal-1.18.1.1, GLFW:setup.Cabal-1.18.1,
GLFW:setup.Cabal-1.18.0, GLFW:setup.Cabal-1.16.0.3, GLFW:setup.Cabal-1.16.0.2,
GLFW:setup.Cabal-1.16.0.1, GLFW:setup.Cabal-1.16.0, GLFW:setup.Cabal-1.14.0,
GLFW:setup.Cabal-1.12.0, GLFW:setup.Cabal-1.10.2.0, GLFW:setup.Cabal-1.10.1.0,
GLFW:setup.Cabal-1.10.0.0, GLFW:setup.Cabal-1.8.0.6, GLFW:setup.Cabal-1.8.0.4,
GLFW:setup.Cabal-1.8.0.2, GLFW:setup.Cabal-1.6.0.3, GLFW:setup.Cabal-1.6.0.2,
GLFW:setup.Cabal-1.6.0.1, GLFW:setup.Cabal-1.4.0.2, GLFW:setup.Cabal-1.4.0.1,
GLFW:setup.Cabal-1.4.0.0, GLFW:setup.Cabal-1.2.4.0, GLFW:setup.Cabal-1.2.3.0,
GLFW:setup.Cabal-1.2.2.0, GLFW:setup.Cabal-1.2.1, GLFW:setup.Cabal-1.1.6,
GLFW:setup.Cabal-1.24.1.0 (constraint from minimum version of Cabal used by
Setup.hs requires >=3.2)
[__1] fail (backjumping, conflict set: GLFW, GLFW:setup.Cabal)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: GLFW:setup.Cabal, GLFW


To Reproduce

  • Clone GLFW-0.5.2.5.
  • Try to build with recent Cabal.

Expected behavior
A warning is issued that custom-setup is a required stanza when using custom build type, or possibly other friendly actions are taken.

System information

% cabal-1d320e8a5 --version
cabal-install version 3.5.0.0
compiled using version 3.5.0.0 of the Cabal library 
% ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.10.2

Most helpful comment

I made Cabal straight out fail, if

  • cabal-version: 1.24 or later
  • build-type: Custom
  • there is no explicit custom-setup.

Q: Why only when cabal-version: 1.24.
A: Because it's the first version where it's legal to specify it.

Q: Why not warn on older versions?
A: Because it's not wrong to omit it. This is similar as to asking GHC to have some warning always on by default (not in -Wall, but always).


but I would never think of running cabal check in this situation.

cabal check is the lint-like command cabal has. I can think of various situations where things don't work, but cabal check is able to point them out.

Q: Why not cabal check always when one cabal v2-build, cabal v2-repl?
A: Because cabal check isn't always right, and is on purpose quite verbose. It is also slow (e.g. it hits file system to check whether files exist)

All 9 comments

The bound is there by design. Check the code for the reason (I don't remember it from top of my head).

Solver errors are unfortunately sometimes cryptic, as in, you have to know what to look for. Making good errors solvers for NP-hard problems is hard problem :)

In other words, I don't think we can do anything here.

Of course you can. When build type is custom and there is no custom-setup stanza, you can issue a warning that such a stanza is advisable.

% cabal check
Warning: From version 1.24 cabal supports specifying explicit dependencies for
Custom setup scripts. Consider using cabal-version >= 1.24 and adding a
'custom-setup' section with a 'setup-depends' field that specifies the
dependencies of the Setup.hs script itself. The 'setup-depends' field uses the
same syntax as 'build-depends', so a simple example would be 'setup-depends:
base, Cabal'.

Nice, but I would never think of running cabal check in this situation.

I think there is a difference of mind sets here. You are in perhaps top 1% of Cabal users ordered by expertise. If something seems trivial to you, it does not mean that it will be accessible to an average user. I have been using Cabal for something like a decade, and this error puzzled me.

I made Cabal straight out fail, if

  • cabal-version: 1.24 or later
  • build-type: Custom
  • there is no explicit custom-setup.

Q: Why only when cabal-version: 1.24.
A: Because it's the first version where it's legal to specify it.

Q: Why not warn on older versions?
A: Because it's not wrong to omit it. This is similar as to asking GHC to have some warning always on by default (not in -Wall, but always).


but I would never think of running cabal check in this situation.

cabal check is the lint-like command cabal has. I can think of various situations where things don't work, but cabal check is able to point them out.

Q: Why not cabal check always when one cabal v2-build, cabal v2-repl?
A: Because cabal check isn't always right, and is on purpose quite verbose. It is also slow (e.g. it hits file system to check whether files exist)

I see no difference — it fails either way, with exactly the same console output.

I made Cabal straight out fail, if

  • cabal-version: 1.24 or later

Hackage version of GLFW (https://hackage.haskell.org/package/GLFW-0.5.2.5/GLFW.cabal) has cabal-version: 1.12, so conditions to error aren't satisfied.

As far as I see this, the problem is that GLFW package is not actively maintained. Cabal-2.0 (the next after Cabal-1.24) is three years old now.

If you say so.

BTW

Note that this binding comes with an older GLFW C version 2.7.9 due to incompatible API changes in GLFW since 3.0 (for example, the removal of texture functions). If you want to use newer GLFW C versions, install Haskell package GLFW-b instead.

It uses no custom-setup tricks and should work everywhere.

Was this page helpful?
0 / 5 - 0 ratings