Proposed ghc-pkg and cabal feature - right list?
Axel.Simon at in.tum.de
Tue Mar 16 03:21:35 EDT 2010
I'm replying to Simon M. and myself, as should have sent my first
reply to the ghc users list, I guess.
On 14.03.2010, at 10:54, Axel Simon wrote:
> Hi Dan,
> I reply to libraries, I think that's the right list for Cabal.
> On 13.03.2010, at 21:39, Dan Knapp wrote:
>> There doesn't seem to be a mailing list for Cabal itself, so I'm
>> posting here. I came up with an idea for a small feature that I
>> believe would make a useful addition to ghc-pkg and Cabal. I'm
>> willing to implement it myself, but I have had some previous
>> experiences with other projects where I did some work and then the
>> maintainers said "sorry, not interested", so I want to gauge interest
>> before I start. Who should I talk to?
>> The feature itself is this: Arbitrary key-value pairs in Cabal
>> package files and the installed-package database. The use-case is
>> an application supporting plugins to discover installed plugins
>> compatible with it, interrogating these fields through the GHC API.
> For Gtk2Hs I would like to have a similar feature. Gtk2Hs is a
> wrapper for Gtk+. It evolves on its own (for which the package has a
> version number) but it may wrap different versions of Gtk+.
> I think people using Gtk2Hs need to be able to conditionally compile
> certain code fragments, depending on which Gtk+ version Gtk2Hs
> wraps. However, I had something simpler in mind than providing any
> kind of key,value pairs: I would like to "export" certain Cabal
> flags into the package, which could be as easy as specifying:
> Flag gtk_2_2
> Description: Build objects for Gtk+ version 2.2.
> Exported: True
> Flag gtk_2_4
> Description: Build objects for Gtk+ version 2.4.
> Exported: True
> Flag gtk_2_6
> Description: Build objects for Gtk+ version 2.6.
> Exported: True
> where the 'Exported' would mean that this flag should be added to
> the package data base. A package would then be
> if the first two flags would be set by Cabal. A package could then
> depend on gtk-0.10.4 in which certain flags are set. Moreover, I
> would then want cabal to compile a users package with -Dgtk_2_2 -
> Dgtk_2_4 so the user can use CPP to conditionally compile code.
> You suggestion of using arbitrary key,value pairs is more general
> and needs more thought. You would have to extend Cabal quite a bit
> whereas my proposal is more lightweight in that it can build on top
> of Cabal's Boolean flags. May I ask:
> - could you express your package properties using Boolean flags
> (which are set by Cabal automatically)?
> - if not, could you not express your plug-in concept using several
>> For example, my content-management system FruitTart could enumerate
>> the list of installed packages looking for packages which export a
>> field "fruit-tart-plugin-interface-version" with a numeric value
>> matching the interface version it's expecting.
I'm not quite sure I understand the use case here. Are you saying you
want to writing something within Cabal? Or do you want to use the
Cabal API to find out if a certain package is available?
If you're talking about dynamic plug-ins then I assume it must be the
latter. Besides the technical difficulty of loading a GHC package
dynamically (that I don't know anything about), what prevents you from
looking for a package that contains just the plug in?
On 15.03.2010, at 16:38, Simon Marlow wrote:
> My first thought was "hmm, there must be another way to do that",
> but I can't think of one, or at least a good one.
> Perhaps having arbitrary key-value pairs in the package database
> would be a good thing. It would help us to avoid breaking things
> when we need to change the format, for one thing. We could start
> using key-values for new fields rather than adding them to
> InstalledPackageInfo. However, then we have a strange situation
> where some fields get distinguished status in InstalledPackageInfo.
> Of course, for some of those fields we have richer types (e.g.
> License), so it makes sense.
> So for me, I can't see any serious objections to doing this, but I'd
> also ask on the cabal-devel at haskell.org list (in particular we
> should hear what Duncan Coutts thinks).
Before implementing anything like general key,value pairs, I would
like to see the exact usage of these fields? So Dan wants to query
these dynamically using an API. I'm much more interested in having CPP
macros defined so I can compile code conditionally. For this purpose,
the key,value pairs are not necessarily suitable since Dan might want
to define a pair that does not create a valid -Dkey=value instruction
More information about the Glasgow-haskell-users