Perhaps I'm missing something, but why not just cabal-version: >=1.18 ? It will constrain the Cabal version, not cabal-install, but judging from the fix[1] this is what you actually need. [1]: https://github.com/haskell/cabal/commit/d148336e97cda2e3585c453cf9af61bc3635... Roman * Ryan Newton [2013-05-22 22:50:08-0400]

A cabal-install bug https://github.com/haskell/cabal/issues/1284 was fixed recently that pertains to building C libraries with profiling.

As a result, I want a certain packagehttp://hackage.haskell.org/package/atomic-primops-0.1.0.2to test if cabal-install < 0.17.0 is used, and throw a preemptive error. Otherwise this package fails in weird ways at runtime (it's a nasty one).

I noticed with some surprise the following sequence:

* $ cabal --version* * cabal-install version 1.16.0.2* * using version 1.16.0.3 of the Cabal library* * $ cabal clean* * $ cabal install* * $ cat dist/build/autogen/cabal_macros.h | grep VERSION_Cabal* * #define VERSION_Cabal "1.17.0"*

Alright, so that, in retrospect, makes sense. The version is which *my* library is linked with is the relevant one, not the one cabal-install was linked with [1].

So the natural next thought is to move the MIN_VERSION_Cabal test into Setup.hs, and force cabal to use it by setting the build type to Custom. But... I just learned from this ticket that the cabal macros are not available in Setup.hs:

http://hackage.haskell.org/trac/hackage/ticket/326

Uh oh, what's left?

-Ryan

[1] P.S. Personally I'm now using a bash function like below, to force the two versions to be the same:

function safe_cabal_install () { VER=`cabal --version | tail -n1 | awk '{ print $3 }'` cabal install --constraint="Cabal==$VER" $* }

_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel