Proposed ghc-pkg and cabal feature - right list?

[Axel Simon]

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

gtk-0.10.4{gtk_2_2,gtk_2_4}

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

Cheers,
Axel.


> 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.
>
> Once again, I'm not asking anyone to do this work for me - I'm eager
> to get my hands dirty and do it myself.  I just want to find out what
> the process would be to get it accepted, once it works.
>
> Thanks in advance,
>
> -- 
> Dan Knapp
> "An infallible method of conciliating a tiger is to allow oneself to
> be devoured." (Konrad Adenauer)
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users