What kind of output should be produced is also controllable through a couple of options.
-fhs-to-c
The -fhs-to-c instructs the compiler that the IDL input
should be interpreted as specifying a C library that we want to
generate a Haskell binding for. That is, generate stubs which allows
Haskell code to call C (hence the name :-)
-fcom
The option causes the compiler to interpret the methods in a
interface declaration to invoke the method via its
``interface pointer'' (see below for options that control how
interface pointers themselves are to be represented.)
If the interfaces are ``Automation compatible'', that is, they support
the IDispatch COM interface, the generated stubs can also be
used directly with the Automation-friendly
HaskellScript.
-fautomation
A close cousin of -fcom, which allows you to specify
a collection of command-line options that are useful for generating
``Automation compatible'' stubs. The 'primitive' options it
expands to are:
-fno-export-list
-fcom
-fcoalesce-methods
-fno-gen-binary-interface
-fenum-instances
-fno-gen-enum-marshallers
--hugs
Instructs the compiler to generate Haskell stubs that can be used by
versions of Hugs that `just' support primitive declarations (and
not the new GHC/Hugs FFI). With this option on, a .c file is
also generated, containing the stubs which perform the external calls,
see Section
Compiling Hugs stubs for how to compile it up.
--gc
To perform the actual external calls, the HaskellDirect generated
stubs uses by default the Hugs/GHC
FFI. If,
for whatever reasons, you want to use Green Card to generate the code
that performs the external calls, the --gc option is your
friend.
-g
Generate Glasgow Haskell specific code that performs the external
calls (i.e., _ccall_ and _casm_s). Don't use this
option unless you absolutely have to, since the new FFI is really
a lot more expressive (and where the future is at.)
--gen-headers
Convert the IDL fed as input into C declarations and emit into a C header file.
If used in conjunction with the -fshort-header, the generated
header file output is dumped in ``short form'', that is, interface
declarations are not expanded, so from
interface IA { m1 ; m2 }
you only get
typedef struct IA* IA;
emitted into the header file. This is just what you want when using the generated header file in order to have the generated C stubs compile correctly.
--gen-tlb
Instruct the compiler to emit a type library for every
library declaration it encounters in its input. Type
libraries can be viewed as a binary representation of IDL, and are
used by OLE Automation clients and servers.
This option is only supported on Win32 platforms.
--skeleton
When operating in Haskell component mode, emit a skeleton implementation of the component's methods. For more information on what this fills in, see Section Haskell servers
--gen-defs
A Win32 specific option, which causes the IDL compiler to emit
a module definition file (with the suffix .def) for
each of the DLL you're trying to interface to. This option is
of some use when you're interfacing to 'hostile' DLLs that don't
come with separate import libraries. By generating the .def
files for you, you can then easily build the import libraries using
standard tools (see Win32 documentation for details on how to do
this).
--h1.4
The default is for the IDL compiler to emit Haskell code that
comply, where possible, with the Haskell 98 standard. If you're
working with a Haskell 1.4 system, the --h1.4 option
comes in very useful.
-noC
Don't write out the generated stubs. Sometimes useful when debugging.