Extending the dependency syntax

Isaac Jones ijones at syntaxpolice.org
Fri Jul 29 15:54:25 EDT 2005

"Simon Marlow" <simonmar at microsoft.com> writes:

>> 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 :-)

I'm just concerned about parsing version strings from --version; that
seems like it may be hard to maintain and very tool-dependent.

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

I absolutely agree that this is a good extension to build-depends.

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

Oh :(

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

I didn't mean to give you the impression that I don't like your
extension (modulo some syntax wibbles) I just want to vote for some
care in extending the .cabal file rather than the library or the setup



More information about the Libraries mailing list