On 11 August 2005 04:38, Isaac Jones wrote:

"Simon Marlow" writes:

(snip)

...

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.

The example I wrote above is deterministic: it doesn't pick up dependencies from the environment and change its configuration automatically (this isn't accidental). I'm going with the derministic-dependencies-by-default approach, which seems better. It's possible to write non-deterministic dependencies with this scheme. Perhaps that's a problem. A few messages back I mentioned that we might have an --auto-enable switch to get back the handy non-deterministic behaviour. I can't immediately see how to make it work (eg. we don't want --enable-debug enabled automatically if HUnit is available). But I don't consider the lack of --auto-enable to be a big deal - good OS packaging systems like Gentoo provide this anway.

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...

Ok, but separating these dependencies will mean that you can't combine them. eg. you can say "if I have GHC 6.4 and wxHaskell then ... else ...". And separating them seems to make the system more complicated rather than less... but I don't feel that strongly.

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?

I'm just suggesting extending the syntax of build-depends in a backwards-compatible way.

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.

I put some thought into the --with-foo thing too, and Dimitry's suggestion, but again I think we should deal with one thing at a time.

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?

My feeling is that Cabal's build-depends should deal with dependencies that it needs to know about in order to build, install and register the package. Everything else should be pushed into the OS-level packager.

I have been thinking that Cabal should worry about 1 and 2 only, and let the OS package system worry about 3 and 4,

bingo :)

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? ... 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?

They're definitely important when building an OS package from a Cabal package, and we'd like to automate this process as much as possible. Therefore it might be useful to have a consistent way to specify hints to the OS packager, extra dependencies and so on. This might take the form of a naming scheme for OS-packaging hint files, or extra sections in the .cabal file. I vote for punting on (3) and (4), but allowing hints to be provided for passing these dependencies to the OS packager.

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] ),

This one's easy: "mozilla? (>=mozilla-1.4)" (if I got the ebuild syntax right). The GHC section reduces to >=ghc-5.04. The --enable-debug section reduces to "debug? ( HUnit-1.0 )", or goes away entirely if you don't care about debugging in the OS package. Basically, the existing build-depends syntax is a subset of what Gentoo allows, and I'm proposing a superset (modulo the lack of depdencies on C libraries etc.). The .cabal->.ebuild generator would have to fail on dependencies that it didn't understand - I don't think this is a huge problem, since complex dependencies will be rare, and there will be a way for the Cabal packager to provide hints to the .cabal->.ebuild generator. I don't think we should restrict ourselves to the lowest common denominator of Gentoo, Debian, FreeBSD, RPM, etc. Duncan, does this sound plausible? Cheers, Simon