Cabal package description sytax

[Ross Paterson]

[Einar, I hope you don't mind me posting your reply on the list]

On Tue, Nov 30, 2004 at 12:06:46AM +0200, Einar Karttunen wrote:
> Ross Paterson <ross at soi.city.ac.uk> writes:
> > 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.
> 
> Actually cpp cannot do that. If the -I options are not known when the 
> Setup.description is written (otherwise they could be directly
> specified) there is usually no way of getting them with cpp.
> 
> Generally you cannot #include any C headers because that would break
> cabal (they usually come with extra baggage) and without any #includes,
> there is very little information to use. 

#including a C header generated by configure is precisely what I was
proposing to allow.  That's what happens now with the fptools libraries.
(Though they use installed package descriptions, which also happen to
contain enough build information for Hugs.)  I know that Cabal doesn't
like the blank lines cpp generates, and I was proposing a change (which
SimonM had already done on the fptools copy).

> If you are thinking about including a generated file with cpp then it is
> probably simpler to just append things to the Setup description with a
> script. I cannot think of real scenarios when this would be helpful.

Sven suggested some:

name:           PACKAGE_TARNAME
version:        PACKAGE_VERSION
maintainer:     PACKAGE_BUGREPORT

Similarly extra include directories, libraries, etc.  In some cases,
part of the info will be always the same, but part is system-dependent,
so you want to substitute, not just append.  Also #if's are very useful.