On Thu, 2007-10-25 at 12:48 +0100, Ross Paterson wrote: > On Thu, Oct 25, 2007 at 01:17:43PM +0200, Thomas Schilling wrote: > > I presume the final interface should be to give the user a simple way to > > query the dependenies by giving assignments for OS, arch, > > implementation, etc. and then dynamically (yes, using JavaScript) > > updating the dependency list. It shouldn't be hard to generate the > > necessary code from the Cabal file. I think the current way is okay for > > now, though. > > The pages are CGI output, so those could be extra parameters. > > > The main problem with using this representation is, that it assumes that > > flags are only used to let Cabal decide dependencies based on present > > dependencies. This is exactly the part I would *not* want to use them > > for -- they are meant to be used to enable/disable certain features > > like, e.g., using GTK or WXWindows or building with debugging support. > > I don't quite follow you, but it treats optional features (if's without > else's) as not creating dependencies.
The point is, that flags like "old-base" or "bytestring-in-base" (as, for example, in [1]) are used solely to dispatch on the version of the base package. It should not be necessary for the user to invent flag names for such uses. > > > Duncan is currently implementing his proposal to use the 'package(...)' > > predicate to enable specifying different dependencies depending on the > > version of some package. > > Is that written up somewhere? http://www.haskell.org/pipermail/cabal-devel/2007-October/001189.html / Thomas [1] .. http://hackage.haskell.org/packages/archive/cabal-install/0.4.0/cabal-install.cabal _______________________________________________ cabal-devel mailing list [email protected] http://www.haskell.org/mailman/listinfo/cabal-devel
