Multiple dependencies on the same package (was discussion on #haskell)
Hello There was a discussion about the semantics of the package dependencies on #haskell. Continuing here for clarity. build-depends: foo > 1 && < 3 vs build-depends: foo > 1, foo < 3 and the same with configuration stuff: packages(foo >1 && < 3) vs packages(foo > 1) && packages(foo < 3) Current Cabal and the configurations patch interpret these as: * "packages(foo >1 && < 3)" * there exists a package foo such that the version is >1 and <3 * "packages(foo > 1) && packages(foo < 3)" * there exists a package foo such that the version is >1 *and* * there exists a package foo such that the version is <3 This means that the semantics are very simple, each package and depend can be handled in isolation. This has not caused problems but should be documented more clearly. The alternative solution is to make package names have per-configuration and per-build-depend-line specific scope and add an environment to the semantics. This would eliminate a class of errors, but on the other hand make reasoning about the semantics harder. e.g. is this a tautology: configuration: (package(foo > 10) || flag) || (package(foo < 10) || !flag) Under the current semantics it is a tautology, since regardless of how the foo match goes we have: (x || a) || (y || !a) <=> (x || y || (a || !a)) <=> True With the new semantics this would depend on the evaluation strategy. Clearly there is no version of foo which satisfies the dependencies. - Einar Karttunen
On Thu, 2006-08-10 at 19:31 +0300, Einar Karttunen wrote:
Hello
There was a discussion about the semantics of the package dependencies on #haskell. Continuing here for clarity.
build-depends: foo > 1 && < 3 vs build-depends: foo > 1, foo < 3
and the same with configuration stuff:
packages(foo >1 && < 3) vs packages(foo > 1) && packages(foo < 3)
Current Cabal and the configurations patch interpret these as: * "packages(foo >1 && < 3)" * there exists a package foo such that the version is >1 and <3
* "packages(foo > 1) && packages(foo < 3)" * there exists a package foo such that the version is >1 *and* * there exists a package foo such that the version is <3
This means that the semantics are very simple, each package and depend can be handled in isolation. This has not caused problems but should be documented more clearly.
The alternative solution is to make package names have per-configuration and per-build-depend-line specific scope and add an environment to the semantics. This would eliminate a class of errors, but on the other hand make reasoning about the semantics harder.
Isn't the semantics quite simple: for each package mentioned in build depends, a candidate package must satisfy all constraints. for the current implemented semantics it's: for each dependency there must exist a candidate package that satisfies it. So "build-depends: foo > 1, foo < 3" means linking with foo twice (and possibly different versions)! This seems like nonsense. If that's what it means then it should be an error condition with a helpful message to use "build-depends: foo > 1 && < 3" instead. Similarly if we go with "packages(foo >1 && < 3)" meaning something different from "packages(foo > 1) && packages(foo < 3)" then is the latter not simply an error? Duncan
participants (2)
-
Duncan Coutts -
Einar Karttunen