extended foreign decls

[Fergus Henderson]

On 03-Jan-2001, Marcin 'Qrczak' Kowalczyk <qrczak at knm.org.pl> wrote:
> Wed, 3 Jan 2001 21:44:03 +1100, Fergus Henderson <fjh at cs.mu.oz.au> pisze:
> 
> > Personally I'd rather have a single well-designed convenient foreign
> > language interface as a standard part of the language, rather than
> > having a minimalistic foreign language interface in the language
> > standard and having convenience provided by a separate tool (or by
> > several competing separate tools).  But I understand why you might
> > differ on that point.
> 
> I would prefer that too if it was possible, but it does not look well.
> Interfacing to C is complex enough, it's yet worse for other languages.
> 
> A problem: HsFFI includes some C headers (stdint.h, which includes
> among others features.h on glibc). There are headers like stdio.h (if
> I remember correctly) which provide certain prototypes or macros only
> when certain macros are defined, like _XOPEN_SOURCE and _GNU_SOURCE.
...
> #option -optc-D_GNU_SOURCE -optc-D_XOPEN_SOURCE=500
> #undef _GNU_SOURCE
> #define _GNU_SOURCE 1
> #undef _XOPEN_SOURCE
> #define _XOPEN_SOURCE 500
> 
> Ugly, isn't it?
...
> Would a builtin support predict all possible uses of C features?

Well, the Mercury language specification doesn't say anything about
compiler options, since they tend to vary between implementations.
But with the Mercury build environment (a de facto standard, I suppose ;-),
you can solve that problem by putting

	CFLAGS = -D_GNU_SOURCE -D_XOPEN_SOURCE=500

in your Mmakefile, or

	CFLAGS-foo = -D_GNU_SOURCE -D_XOPEN_SOURCE=500

if you only want it for module `foo'.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.