Cabal package description sytax

Hi Sven,
I'm having problems understanding the Cabal package description syntax (I can't find a formal spec),
There won't be a formal spec until we're closer to freezing it.
especially the use of quotes. Some field values can be quoted, others can't, but I can't see any general principle here.
The principal is that if there are fields that contain multiple values and unpredictable syntax, then you can use quotes. Maybe the only place that this is true is for file paths. You may note that the example in the proposal has a comma.
My problem in particular is that I want to use the values from autoconf's AC_INIT (PACKAGE_NAME, PACKAGE_VERSION, PACKAGE_BUGREPORT) for some package fields (name, version, maintainer), but the former have double quotes around them, while ghc-pkg either doesn't allow them (name, version) or includes the quotes into the value (maintainer).
I'm a little unclear about what you're looking for wrt the interaction between autoconf, cabal, and ghc-pkg.
IMHO this should be more consistent and unified, and a possible solution would be that quotes are handled like they are in shells, so "blah" and blah are the same.
I think I like this idea for the cabal package description, and it would definitely be good to have consistency between the public parts of HC-pkg and cabal's package description. Unless anyone has objections to allowing quotes in all the fields, you should feel free to alter cabal's parser and send me a patch (it'll probably be a few days before I can do any serious cabal hacking). Since it's necessary for some fields, it'll probably simplify it if quotes are allowed everywhere. Opinions anyone? I'm not sure what this'll do when it dumps out a ghc-pkg description file, though, so some care should be taken (maybe that's what you're getting at above). peace, isaac

On Sun, Nov 28, 2004 at 10:49:44PM -0800, isaac jones wrote:
On Sat, Nov 27, 2004 at 03:04:00PM +0100, Sven Panne wrote:
My problem in particular is that I want to use the values from autoconf's AC_INIT (PACKAGE_NAME, PACKAGE_VERSION, PACKAGE_BUGREPORT) for some package fields (name, version, maintainer), but the former have double quotes around them, while ghc-pkg either doesn't allow them (name, version) or includes the quotes into the value (maintainer).
I'm a little unclear about what you're looking for wrt the interaction between autoconf, cabal, and ghc-pkg.
There's an opportunity here to make another small extension to the simple build infrastructure, namely to preprocess package descriptions with cpp, possibly using header files generated by the configure step. That would be enough for the simple build to handle packages like X11, HGL, GLUT, OpenGL and OpenAL, where building is system-dependent. Indeed almost all of the packages in fptools/libraries could be handled this way. It would help if (at least) the name, version and maintainer fields allowed optional quotes as Sven suggests, so one could use the PACKAGE_* defines straight from configure. Also, the package description would need a few more fields (extra-ld-opts, extra-cc-opts and extra-frameworks) and a flag to say whether all Haskell sources should be preprocessed with cpp. It would also need to ignore blank lines (as GHC does), because #if's tend to generate quite a few of them, and these are even useful inside fields (e.g. module lists). I realize that this conflicts with the current stanza idea.

Ross Paterson
There's an opportunity here to make another small extension to the simple build infrastructure, namely to preprocess package descriptions with cpp, possibly using header files generated by the configure step. That would be enough for the simple build to handle packages like X11, HGL, GLUT, OpenGL and OpenAL, where building is system-dependent. Indeed almost all of the packages in fptools/libraries could be handled this way.
Using cpp does not help with many packages, using e.g. programs like foo-config. This is true for at least gtk, fltk, and so on. Also to include the headers containing the definitions on needs system dependent -I options for cpp... Currently I am using a Setup.description.in from which a dummy Makefile creates the real Setup.description: LFL=`fltk-config --libs | xargs dirname` Setup.description: Setup.description.in cp Setup.description.in Setup.description sh -c "[ $(LFL) = /usr/lib ] || echo Extra-Lib-Dirs: $(LFL) >> Setup.description" I don't think there is a really elegant way of doing this. Preprocessing could be done in Setup.lhs too, but isn't that even more dirty?
It would help if (at least) the name, version and maintainer fields allowed optional quotes as Sven suggests, so one could use the PACKAGE_* defines straight from configure. Also, the package description would need a few more fields (extra-ld-opts, extra-cc-opts and extra-frameworks) and a flag to say whether all Haskell sources should be preprocessed with cpp. It would also need to ignore blank lines (as GHC does), because #if's tend to generate quite a few of them, and these are even useful inside fields (e.g. module lists). I realize that this conflicts with the current stanza idea.
There is currently a pending patch to add support for Extra-Lib-Dirs. - Einar Karttunen

On Mon, Nov 29, 2004 at 01:59:45PM +0200, Einar Karttunen wrote:
Ross Paterson
writes: There's an opportunity here to make another small extension to the simple build infrastructure, namely to preprocess package descriptions with cpp, possibly using header files generated by the configure step. That would be enough for the simple build to handle packages like X11, HGL, GLUT, OpenGL and OpenAL, where building is system-dependent. Indeed almost all of the packages in fptools/libraries could be handled this way.
Using cpp does not help with many packages, using e.g. programs like foo-config. This is true for at least gtk, fltk, and so on. Also to include the headers containing the definitions on needs system dependent -I options for cpp...
True, simple will only get you so far, but the point is you can get quite a bit further for a small cost. (But if you only need the -I options for source files, not Setup.description, then cpp can put them in an extra-cc-opts field.) You could have a configure that calls fltk-config --libs and stashes the result -- a bit clunky, but fits the interface.
participants (3)
-
Einar Karttunen
-
isaac jones
-
Ross Paterson