"Simon Marlow"
build-depends: --enable-ghc? ( ghc>=6.4 ? [ghc64] | ghc>=5.04 ? [ghc-old]) | --enable-hugs? [hugs] | true ? true, -- other compilers are allowed --enable-debug? (HUnit-1.0, [debug]) | true? [release] --enable-gnome? ( libglade >= 2, gtksourceview >= 0.6, gconf >= 2, [gnome] ), --enable-mozilla? ( mozilla >= 1.4, [mozilla] ), --enable-doc? ( haddock >= 0.6 )
What happens now with the issue that Duncan mentioned, where the built system picks up configuration information from the build / configure environment that's different from the user's environment? It could either pick up too much or too little. For "too little" we could use the --enable flags to override the detection mechanism, and maybe a --disable-all-detection mechanism similar to the -fhide-all-packages mechanism would be useful. One problem is that --enable-foo doesn't necessarily exist for optional dependencies. Another point: The dependency syntax you show mixes packages and pseudo-packages like GHC, alex, etc... I don't think we should use the same syntax / field for this, since in reality, they have separate namespaces. In fact you might be insane enough to want to talk about them separately: maybe you have the haxml library installed, but not the haxml toolchain... maybe you want the ghc executable, but not the ghc package... Stuff like GHC is auto-detected by looking in the PATH, which is dicier than using the package configuration database for a few reasons: 1) we have to pull tricks like: HC-pkg should be found at compiler-path++"-pkg". there may be other special cases out there, 2) we need to add a --with-tool= flag to configure for each tool, along with -extra-tool-opts 3) we can only handle tools we know about. We used to have a distinction between depends and build-depends, but we threw that away, I think because we weren't using the non-build-depends stuff at all... I note that having separate depends vs build-depends fields doesn't actually fix the above problems. BTW, are you suggesting that we change the meaning of depends and really adding a build-depends field? There are at least four kinds of simple dependencies, not taking into account configurations: 1) build-depending on packages - which is what depends: means now. This is always a build-time dependency. 2) build-depending on executables like GHC - that the simple build infrastructure knows about / needs. It would also be nice if we had a more sensible way of adding --with-foo= flags, extra-foo-opts, and configure-time detection for stuff in this category. 3) run-time depending on executables like gpg, gnome, etc. These are likely to be executables that Simple has never heard of before. 4) build-depending on stuff that the simple build infrastructure doesn't know about. This may not be very common, but folks not using Distribution.Simple may want to use this field to express dependencies too, so it would be nice if we could express build-time dependencies on non-package tools which we don't already know about. In reality, there are even more kinds :( The original request, I believe, was for better support of tool-depends mainly 2, but perhaps 3 and 4 are also important? 3 is a very common situation in Debian, and 4 is important for completeness for systems that don't want to use Distribution.Simple, and maybe for stuff like libglade? I have been thinking that Cabal should worry about 1 and 2 only, and let the OS package system worry about 3 and 4, but Duncan's requirements open the door to 3, and it's not going to be obvious to people that they can't talk about tools that Simple doesn't know about. In fact, it snuck into the above example. How the heck does Distribution.Simple know what version of Mozilla is installed? Maybe you didn't really mean that? But I do think that if we're overhauling the dependency syntax, we should think about all kinds of dependencies so we don't paint ourselves into a corner. 1 is the only kind that currently has a flexible infrastructure; 2 is done now, but can be sloppy sometimes; as I haven't always added --with-foo= flags when we need them and such. But how can we be flexible about 3 and 4? Are they important? Is $PATH searching good enough? Probably not; how do we discover versions? Maybe we should have a database similar to the hc-pkg database, but for tool dependencies, and we could include stuff like alex. But now I'm really drifting into the area of OS package management systems, and how do we get mozilla to register its version with the cabal package manager? Am I being too much of a perfectionist in trying to be complete here? Should we really just allow 1 and 2 and punt on the rest? Is it important to distinguish between 1 and 2? These are the questions I had in mind when I said earlier that cabal could become a generic packaging system if we kept going down this path. Also, I'm not sure we're really doing gentoo a favor by making the dependency syntax so complex. I think Duncan wanted to be able to automatically parse the cabal file and figure out the dependencies for alex and such, but now he's faced with: --enable-mozilla? ( mozilla >= 1.4, [mozilla] ), so he'll either have to figure all that out, or maybe he'll punt and suck out only the required dependencies.
Finally, are you intending to allow multiple executable stanzas inside configurations?:
I've been avoiding this issue for now. I believe we need to completely redesign the way multiple executables are handled, and provide a more general framework for a package that contains multiple libraries & executables (essentially a wrapper for multiple packages with interdependencies). I know Isaac is thinking about this too. Let's deal with one issue at a time.
Yes, that is still high on my list! Stayed tuned. peace, isaac