Extending the dependency syntax

[Simon Marlow]

On 28 July 2005 22:24, Isaac Jones wrote:

> "Simon Marlow" <simonmar at microsoft.com> writes:
> 
>> So here's a strawman proposal to address some of the use cases raised
>> recently[1] that Cabal doesn't currently support well.  This is just
>> a first attempt; I expect we'll need to make changes or start over
>> if we discover cases that it doesn't handle.
> 
> (snip proposal)
> 
> Lots of this is stuff I've been wanting to ad at some point.  I think
> that rather than overloading the build-depends field, we should add a
> new field for tool dependencies; otherwise, we could get name
> conflicts between the two and such.

ok - I put them in the build-depends field because I wanted to do the
cool stuff with optional stanzas and use it with compiler and tool
versions too.  There's no reason you couldn't do this in a separate
field.

> I'm not positive that the simple build infrastructure would be able to
> take all of the information in the tool-dependendencies into account;
> for instance, discovering the version of happy and ghc might be a bit
> tricky and error prone.

We already discover the version of GHC.  And it can't be any more tricky
than using autoconf :-)

> (snip)
>> ----------------
>> name: mylib
>> version: 1.0
>> exposed-modules: My.Lib
>> build-depends:
>>   base>=1.0
>>   (ghc>=6.4 || ghc>=6.2 [ghc62] || hugs-any [hugs])
> 
> Debian has something like this, where you can specify optional
> dependencies.  I've always planned to implement something like this
> for Cabal.
> 
> At the same time, I think we need to be careful not to re-invent make
> and re-invent dpkg / rpm via feature-creep.  I understand Duncan's
> desire to have absolutely everything automated for gentoo without the
> gentoo packager having to intervene, but that's just what the OS
> packagers have been dealing with for every language.  I want Haskell
> to be easier than other languages (historically, it's been harder) but
> if we make the package syntax more and more complex, I think we run
> the risk of expending a lot of energy for a small amount of benefit by
> creating a whole new language for packages.

I don't think it's a question of re-invention - we really do need a more
expressive language for dependencies in Cabal.  Otherwise some packages
will have dependencies that can't be written precisely in the .cabal
file, and we'll end up with ugly hacks to work around it.  Or we have to
allow the build-depends field to be generated by the Setup script,
perhaps via hooks.  But that means Visual Studio won't be able to work
with a package with a dynamic build-depends field.

I think a small extension to build-depends is warranted - and I think
the suggestion I put forward has pretty good bang per buck.

> OTOH, maybe Haskell can become the generic packaging language, ...
[ daydreaming deleted :-) ]

> For Debian packages in most languages, we have a hunk of executable
> stuff for building and installing, and a relatively small amount of
> metadata to deal with dependencies and what-have-you.  I think we
> should try to stick to that model wherever possible, of course,
> improving upon Debian where we can.

That's fine by me, as long as *enough* of the metadata is concrete so
that our tools can manipulate it as necessary.  There's always going to
be a tension here, but I think we can use the dev environment example as
a dipstick to tell us whether we've got enough concreteness.

>> [ghc62]
>> other-modules: Compat.Ghc62
>> 
>> [hugs]
>> other-modules: Compat.Hugs
> 
> Here we're starting to get complicated, though, and I'm a bit scared
> of this complication.  Presumably, then you have something in the
> source code to optionally #include the correct module?

Ok, this wasn't a great example.  Yes, you'd also have to optionally
import the right module using conditional compilation of some kind.  Try
this instead:

[ghc62]
hs-source-dirs: ghc62-compat

[hugs]
hs-source-dirs: hugs-compat

Cheers,
	Simon