[Hackage] #342: Allow automatic resolving of conditionals on more than just build-depends
#342: Allow automatic resolving of conditionals on more than just build-depends -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: hard (< 1 day) | Ghcversion: 6.8.2 Platform: | -----------------------------+---------------------------------------------- We have several classes of dependency that we can express in .cabal files. The most obvious is other Haskell packages via the `build-depends` field. The others are: * C libs (`extra-libraries`) * C headers (`includes`) * other build tools (`build-tools`) * pkg-config packages (`pkgconfig-depends`) * MacOS X frameworks (`frameworks`) And we may end up with more, like Windows assemblies. If we know (by domain-specific means) what dependencies are available then we should be able to automatically resolve flag conditions that depend on them. So each one is it's own namespace and they have different representations of keys. Most use a name and some a version too. Currently `finalizePackageDescription` takes a `Maybe (PackageSet pkg)` as a way of testing if deps are available. We should generalise this to a dep testing function (which is essentially what `finalizePackageDescription` turns it into internally) on a type that has alternatives for each of the dependency namespaces. If we only had to generalise it for package constraints we might go for `Dependency -> [PackageId]` but how should we do it when we have multiple namespaces and some require version constraints and others do not. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/342 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#342: Allow automatic resolving of conditionals on more than just build-depends ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Resolution: Keywords: | Difficulty: hard (< 1 day) Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by duncan): See related: #227 and #262 Oh, also language extensions are a dependency and one we can check for since we know if the compiler we intend to use supports them. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/342#comment:1 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#342: Allow automatic resolving of conditionals on more than just build-depends ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Resolution: Keywords: | Difficulty: hard (< 1 day) Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Changes (by guest): * cc: gwern0@gmail.com (added) -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/342#comment:2 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#342: Allow automatic resolving of conditionals on more than just build-depends ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Resolution: Keywords: | Difficulty: hard (< 1 day) Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by nominolo): From a discussion on `#ghc` we think the following needs to be done: - `resolveWithFlags` is, in principle, agnostic to the kind of dependencies. It works basically as follows: 1. pick a flag assignment 2. determine all dependencies 3. combine duplicate dependencies 4. call the dependency checking function to find out if the dependencies can be satisfied - ATM, step 3 above is too specific to package dependencies. We should generalise the `DependencyMap` datastructure to work for other kinds of dependencies. The semantics should still be that multiple dependencies on the same package/framework/etc. should be combined into one that satisfies both. The best place to implement this probably is inside a `Monoid` instance for a set of dependencies. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/342#comment:3 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#342: Allow automatic resolving of conditionals on more than just build-depends ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Resolution: Keywords: | Difficulty: hard (< 1 day) Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by EricKow): As requested by Duncan, I'm noting here an example of how this would be used by a large application. To support the widest user base possible, darcs allows the user to use either libcurl, libwww or the HTTP package for fetching files. We also have logic such as "if the version of libcurl < 7.19, do not compile in any http support; if the version is > 7.19, but < 7.19.1, compile in HTTP pipelining support, but don't enable it because pipelining support in that version is buggy behind proxy servers; otherwise if libcurl is really new, enable HTTP pipelining by support" This kind of logic we normally store in an autoconf test, but it would be nice if cabal could somehow support it. At the moment, our cabal file defaults to using curl, and disables HTTP pipelining support altogether. The user has to specify -f curl-pipelining to enable it. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/342#comment:4 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#342: Allow automatic resolving of conditionals on more than just build-depends ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Resolution: Keywords: | Difficulty: hard (< 1 day) Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by duncan): Note also cabal-version is another kind of dependency, much like build- depends. This has been bothering darcs users. See also #227. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/342#comment:5 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#342: Allow automatic resolving of conditionals on more than just build-depends ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: HEAD Severity: normal | Resolution: Keywords: | Difficulty: hard (< 1 day) Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Changes (by duncan): * milestone: => Cabal-1.8 -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/342#comment:6 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
participants (1)
-
Hackage