Extending the dependency syntax

[Duncan Coutts]

In message <3429668D0E777A499EE74A7952C382D10432B35C at EUR-MSG-
01.europe.corp.microsoft.com> "Simon Marlow" <simonmar at microsoft.com> writes:
> On 11 August 2005 04:38, Isaac Jones wrote:
> 
> > "Simon Marlow" <simonmar at microsoft.com> 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.

Indeed they do.

If you did want to support this "non-deterministic" behaviour I think it'd be 
enough to have a default on/off for each --enable-foo/-with-foo option. Eg for 
Gtk2Hs when a user builds from source without using any packaging system, it 
defaults to picking up optional deps on glade, gconf etc if they are available 
but a couple debugging/development options default to off.

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

I don't really mind. They're all in the same namespace for Gentoo.

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

In future there will be a real distinction between runtime depends and build 
depends. Once we have shared libs then it may be possible for libs to be 
runtime depends but not build time depends and certainly build tools are build 
time depends and are not required at runtime. This is a more important 
distinction for binary packaging systems like Debian.

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

When building libs/progs that use the FFI then (3), that is C libs + headers 
are propper build time dependencies that really are needed to build the 
package.

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

Yep, this sort of conditional dependency is no problem.

> Basically, the existing build-depends syntax is a subset of what Gentoo
> allows, and I'm proposing a superset

Actually I only showed you a subset of the gentoo deps syntax. I think we'll 
probbly be able to translate whatever we come up with. (The package menager 
anrealy has to deal with some really obnoxious C libs/porgs.) Our only issue 
is in getting enough information out of the .cabal file.

> (modulo the lack of depdencies on C libraries etc.).

Am I allowed to mumble about the lack of hints about depdencies on C libs 
next? :-)

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

Yes, quite plausable. Providing more information would be great. If not all 
packaging systems can make full use of it that's ok.

Indeed it seems a sound principle to me, that the .cabal file can provide 
inforation that the Distribution.Simple system does not even use (eg versions 
of some build tools) but that the distro packaging systems can use.

Duncan