Whitespace cleanup
This commit is contained in:
parent
064f18131d
commit
13894f803b
1 changed files with 155 additions and 153 deletions
|
|
@ -1,11 +1,11 @@
|
||||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||||
<html>
|
<html>
|
||||||
<head>
|
<head>
|
||||||
<title>SWIG and Ocaml</title>
|
<title>SWIG and Ocaml</title>
|
||||||
<link rel="stylesheet" type="text/css" href="style.css">
|
<link rel="stylesheet" type="text/css" href="style.css">
|
||||||
</head>
|
</head>
|
||||||
<body bgcolor="#ffffff">
|
|
||||||
<a name="n1"></a>
|
<body bgcolor="#ffffff">
|
||||||
<H1><a name="Ocaml"></a>31 SWIG and Ocaml</H1>
|
<H1><a name="Ocaml"></a>31 SWIG and Ocaml</H1>
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
|
|
@ -59,20 +59,23 @@
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
This chapter describes SWIG's
|
This chapter describes SWIG's support of Ocaml.
|
||||||
support of Ocaml. Ocaml is a relatively recent addition to the ML family,
|
</p>
|
||||||
and is a recent addition to SWIG. It's the second compiled, typed
|
|
||||||
language to be added. Ocaml has widely acknowledged benefits for engineers,
|
<p>
|
||||||
mostly derived from a sophisticated type system, compile-time checking
|
Ocaml is a relatively recent addition to the ML family,
|
||||||
which eliminates several classes of common programming errors, and good
|
and is a recent addition to SWIG. It's the second compiled, typed
|
||||||
native performance. While all of this is wonderful, there are well-written
|
language to be added. Ocaml has widely acknowledged benefits for engineers,
|
||||||
C and C++ libraries that Ocaml users will want to take advantage of as
|
mostly derived from a sophisticated type system, compile-time checking
|
||||||
part of their arsenal (such as SSL and gdbm), as well as their own mature
|
which eliminates several classes of common programming errors, and good
|
||||||
C and C++ code. SWIG allows this code to be used in a natural, type-safe
|
native performance. While all of this is wonderful, there are well-written
|
||||||
way with Ocaml, by providing the necessary, but repetitive glue code
|
C and C++ libraries that Ocaml users will want to take advantage of as
|
||||||
which creates and uses Ocaml values to communicate with C and C++ code.
|
part of their arsenal (such as SSL and gdbm), as well as their own mature
|
||||||
In addition, SWIG also produces the needed Ocaml source that binds
|
C and C++ code. SWIG allows this code to be used in a natural, type-safe
|
||||||
variants, functions, classes, etc.
|
way with Ocaml, by providing the necessary, but repetitive glue code
|
||||||
|
which creates and uses Ocaml values to communicate with C and C++ code.
|
||||||
|
In addition, SWIG also produces the needed Ocaml source that binds
|
||||||
|
variants, functions, classes, etc.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
@ -84,17 +87,16 @@ If you're not familiar with the Objective Caml language, you can visit
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
SWIG 3.0 works with Ocaml 3.08.3 and above. Given the choice,
|
SWIG 3.0 works with Ocaml 3.08.3 and above. Given the choice,
|
||||||
you should use the latest stable release. The SWIG Ocaml module has
|
you should use the latest stable release. The SWIG Ocaml module has
|
||||||
been tested on Linux (x86,PPC,Sparc) and Cygwin on Windows. The
|
been tested on Linux (x86,PPC,Sparc) and Cygwin on Windows. The
|
||||||
best way to determine whether your system will work is to compile the
|
best way to determine whether your system will work is to compile the
|
||||||
examples and test-suite which come with SWIG. You can do this by running
|
examples and test-suite which come with SWIG. You can do this by running
|
||||||
<tt>make check</tt> from the SWIG root directory after installing SWIG.
|
<tt>make check</tt> from the SWIG root directory after installing SWIG.
|
||||||
The Ocaml module has been tested using the system's dynamic linking (the
|
The Ocaml module has been tested using the system's dynamic linking (the
|
||||||
usual -lxxx against libxxx.so, as well as with Gerd Stolpmann's
|
usual -lxxx against libxxx.so, as well as with Gerd Stolpmann's
|
||||||
<a
|
<a href="http://download.camlcity.org/download/">Dl package</a>.
|
||||||
href="http://download.camlcity.org/download/">Dl package
|
The ocaml_dynamic and ocaml_dynamic_cpp targets in the
|
||||||
</a>. The ocaml_dynamic and ocaml_dynamic_cpp targets in the
|
|
||||||
file Examples/Makefile illustrate how to compile and link SWIG modules that
|
file Examples/Makefile illustrate how to compile and link SWIG modules that
|
||||||
will be loaded dynamically. This has only been tested on Linux so far.
|
will be loaded dynamically. This has only been tested on Linux so far.
|
||||||
</p>
|
</p>
|
||||||
|
|
@ -103,24 +105,24 @@ will be loaded dynamically. This has only been tested on Linux so far.
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
The basics of getting a SWIG Ocaml module up and running
|
The basics of getting a SWIG Ocaml module up and running
|
||||||
can be seen from one of SWIG's example Makefiles, but is also described
|
can be seen from one of SWIG's example Makefiles, but is also described
|
||||||
here. To build an Ocaml module, run SWIG using the <tt>-ocaml</tt>
|
here. To build an Ocaml module, run SWIG using the <tt>-ocaml</tt>
|
||||||
option.
|
option.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
%swig -ocaml example.i
|
%swig -ocaml example.i
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<p> This will produce 3 files. The file <tt>example_wrap.c</tt> contains
|
<p>This will produce 3 files. The file <tt>example_wrap.c</tt> contains
|
||||||
all of the C code needed to build an Ocaml module. To build the module,
|
all of the C code needed to build an Ocaml module. To build the module,
|
||||||
you will compile the file <tt>example_wrap.c</tt> with <tt>ocamlc</tt> or
|
you will compile the file <tt>example_wrap.c</tt> with <tt>ocamlc</tt> or
|
||||||
<tt>ocamlopt</tt> to create the needed .o file. You will need to compile
|
<tt>ocamlopt</tt> to create the needed .o file. You will need to compile
|
||||||
the resulting .ml and .mli files as well, and do the final link with -custom
|
the resulting .ml and .mli files as well, and do the final link with -custom
|
||||||
(not needed for native link). </p>
|
(not needed for native link).</p>
|
||||||
|
|
||||||
<H3><a name="Ocaml_nn4"></a>31.1.2 Compiling the code</H3>
|
<H3><a name="Ocaml_nn4"></a>31.1.2 Compiling the code</H3>
|
||||||
|
|
||||||
|
|
@ -134,28 +136,29 @@ the type of each SWIG'ed module's c_obj is derived from Swig.c_obj_t. This
|
||||||
also allows SWIG to acquire new conversions painlessly, as well as giving
|
also allows SWIG to acquire new conversions painlessly, as well as giving
|
||||||
the user more freedom with respect to custom typing.
|
the user more freedom with respect to custom typing.
|
||||||
|
|
||||||
Use <tt>ocamlc</tt> or <tt>ocamlopt</tt> to compile your
|
Use <tt>ocamlc</tt> or <tt>ocamlopt</tt> to compile your SWIG interface like:
|
||||||
SWIG interface like:
|
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
% swig -ocaml -co swig.mli ; swig -ocaml co swig.ml
|
% swig -ocaml -co swig.mli ; swig -ocaml co swig.ml
|
||||||
% ocamlc -c swig.mli ; ocamlc -c swig.ml
|
% ocamlc -c swig.mli ; ocamlc -c swig.ml
|
||||||
% ocamlc -c -ccopt "-I/usr/include/foo" example_wrap.c
|
% ocamlc -c -ccopt "-I/usr/include/foo" example_wrap.c
|
||||||
% ocamlc -c example.mli
|
% ocamlc -c example.mli
|
||||||
% ocamlc -c example.ml
|
% ocamlc -c example.ml
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<p> <tt>ocamlc</tt> is aware of .c files and knows how to handle them. Unfortunately,
|
<p><tt>ocamlc</tt> is aware of .c files and knows how to handle them. Unfortunately,
|
||||||
it does not know about .cxx, .cc, or .cpp files, so when SWIG is invoked
|
it does not know about .cxx, .cc, or .cpp files, so when SWIG is invoked
|
||||||
in C++ mode, you must: </p>
|
in C++ mode, you must:</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
% cp example_wrap.cxx example_wrap.cxx.c<br>% ocamlc -c ... -ccopt -xc++ example_wrap.cxx.c<br>% ...<br>
|
% cp example_wrap.cxx example_wrap.cxx.c
|
||||||
</pre>
|
% ocamlc -c ... -ccopt -xc++ example_wrap.cxx.c
|
||||||
|
% ...
|
||||||
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<H3><a name="Ocaml_nn5"></a>31.1.3 The camlp4 module</H3>
|
<H3><a name="Ocaml_nn5"></a>31.1.3 The camlp4 module</H3>
|
||||||
|
|
@ -244,8 +247,8 @@ toplevel ocaml interpreter. Consult the ocaml manual for details.
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
When linking any ocaml bytecode with your module, use the -custom
|
When linking any ocaml bytecode with your module, use the -custom
|
||||||
option to build your functions into the primitive list. This
|
option to build your functions into the primitive list. This
|
||||||
option is not needed when you build native code.
|
option is not needed when you build native code.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<H3><a name="Ocaml_nn7"></a>31.1.5 Compilation problems and compiling with C++</H3>
|
<H3><a name="Ocaml_nn7"></a>31.1.5 Compilation problems and compiling with C++</H3>
|
||||||
|
|
@ -273,7 +276,7 @@ In the code as seen by the typemap
|
||||||
writer, there is a value, swig_result, that always contains the
|
writer, there is a value, swig_result, that always contains the
|
||||||
current return data. It is a list, and must be appended with the
|
current return data. It is a list, and must be appended with the
|
||||||
caml_list_append function, or with functions and macros provided by
|
caml_list_append function, or with functions and macros provided by
|
||||||
objective caml.<br>
|
objective caml.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="code"><pre>
|
||||||
|
|
@ -299,66 +302,65 @@ type c_obj =
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
A few functions exist which generate and return these:
|
A few functions exist which generate and return these:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<ul>
|
<ul>
|
||||||
<li>caml_ptr_val receives a c_obj and returns a void *. This
|
<li>caml_ptr_val receives a c_obj and returns a void *. This
|
||||||
should be used for all pointer purposes.</li>
|
should be used for all pointer purposes.</li>
|
||||||
<li>caml_long_val receives a c_obj and returns a long. This
|
<li>caml_long_val receives a c_obj and returns a long. This
|
||||||
should be used for most integral purposes.<br>
|
should be used for most integral purposes.</li>
|
||||||
</li>
|
<li>caml_val_ptr receives a void * and returns a c_obj.</li>
|
||||||
<li>caml_val_ptr receives a void * and returns a c_obj.</li>
|
<li>caml_val_bool receives a C int and returns a c_obj representing
|
||||||
<li>caml_val_bool receives a C int and returns a c_obj representing
|
its bool value.</li>
|
||||||
its bool value.</li>
|
<li>caml_val_(u)?(char|short|int|long|float|double) receives an
|
||||||
<li>caml_val_(u)?(char|short|int|long|float|double) receives an
|
appropriate C value and returns a c_obj representing it.</li>
|
||||||
appropriate C value and returns a c_obj representing it.</li>
|
<li>caml_val_string receives a char * and returns a string value.</li>
|
||||||
<li>caml_val_string receives a char * and returns a string value.</li>
|
<li>caml_val_string_len receives a char * and a length and returns
|
||||||
<li>caml_val_string_len receives a char * and a length and returns
|
a string value.</li>
|
||||||
a string value.</li>
|
<li>caml_val_obj receives a void * and an object type and returns
|
||||||
<li>caml_val_obj receives a void * and an object type and returns
|
a C_obj, which contains a closure giving method access.</li>
|
||||||
a C_obj, which contains a closure giving method access.</li>
|
|
||||||
|
|
||||||
</ul>
|
</ul>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
Because of this style, a typemap can return any kind of value it
|
Because of this style, a typemap can return any kind of value it
|
||||||
wants from a function. This enables out typemaps and inout typemaps
|
wants from a function. This enables out typemaps and inout typemaps
|
||||||
to work well. The one thing to remember about outputting values
|
to work well. The one thing to remember about outputting values
|
||||||
is that you must append them to the return list with swig_result = caml_list_append(swig_result,v).
|
is that you must append them to the return list with swig_result = caml_list_append(swig_result,v).
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
This function will return a new list that has your element
|
This function will return a new list that has your element
|
||||||
appended. Upon return to caml space, the fnhelper function
|
appended. Upon return to caml space, the fnhelper function
|
||||||
beautifies the result. A list containing a single item degrades to
|
beautifies the result. A list containing a single item degrades to
|
||||||
only that item (i.e. [ C_int 3 ] -> C_int 3), and a list
|
only that item (i.e. [ C_int 3 ] -> C_int 3), and a list
|
||||||
containing more than one item is wrapped in C_list (i.e. [ C_char
|
containing more than one item is wrapped in C_list (i.e. [ C_char
|
||||||
'a' ; C_char 'b' -> C_list [ C_char 'a' ; C_char b
|
'a' ; C_char 'b' -> C_list [ C_char 'a' ; C_char b
|
||||||
]). This is in order to make return values easier to handle
|
]). This is in order to make return values easier to handle
|
||||||
when functions have only one return value, such as constructors,
|
when functions have only one return value, such as constructors,
|
||||||
and operators. In addition, string, pointer, and object
|
and operators. In addition, string, pointer, and object
|
||||||
values are interchangeable with respect to caml_ptr_val, so you can
|
values are interchangeable with respect to caml_ptr_val, so you can
|
||||||
allocate memory as caml strings and still use the resulting
|
allocate memory as caml strings and still use the resulting
|
||||||
pointers for C purposes, even using them to construct simple objects
|
pointers for C purposes, even using them to construct simple objects
|
||||||
on. Note, though, that foreign C++ code does not respect the garbage
|
on. Note, though, that foreign C++ code does not respect the garbage
|
||||||
collector, although the SWIG interface does.</p>
|
collector, although the SWIG interface does.</p>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
The wild card type that you can use in lots of different ways is
|
The wild card type that you can use in lots of different ways is
|
||||||
C_obj. It allows you to wrap any type of thing you like as an
|
C_obj. It allows you to wrap any type of thing you like as an
|
||||||
object using the same mechanism that the ocaml module
|
object using the same mechanism that the ocaml module
|
||||||
does. When evaluated in caml_ptr_val, the returned value is
|
does. When evaluated in caml_ptr_val, the returned value is
|
||||||
the result of a call to the object's "&" operator, taken as a pointer.
|
the result of a call to the object's "&" operator, taken as a pointer.
|
||||||
</p>
|
</p>
|
||||||
<p>
|
|
||||||
You should only construct values using objective caml, or using the
|
<p>
|
||||||
functions caml_val_* functions provided as static functions to a SWIG
|
You should only construct values using objective caml, or using the
|
||||||
ocaml module, as well as the caml_list_* functions. These functions
|
functions caml_val_* functions provided as static functions to a SWIG
|
||||||
provide everything a typemap needs to produce values. In addition,
|
ocaml module, as well as the caml_list_* functions. These functions
|
||||||
value items pass through directly, but you must make your own type
|
provide everything a typemap needs to produce values. In addition,
|
||||||
signature for a function that uses value in this way.
|
value items pass through directly, but you must make your own type
|
||||||
</p>
|
signature for a function that uses value in this way.
|
||||||
|
</p>
|
||||||
|
|
||||||
<H3><a name="Ocaml_nn9"></a>31.2.1 The generated module</H3>
|
<H3><a name="Ocaml_nn9"></a>31.2.1 The generated module</H3>
|
||||||
|
|
||||||
|
|
@ -399,11 +401,11 @@ it describes the output SWIG will generate for class definitions.
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
SWIG will wrap enumerations as polymorphic variants in the output
|
SWIG will wrap enumerations as polymorphic variants in the output
|
||||||
Ocaml code, as above in C_enum. In order to support all
|
Ocaml code, as above in C_enum. In order to support all
|
||||||
C++-style uses of enums, the function int_to_enum and enum_to_int are
|
C++-style uses of enums, the function int_to_enum and enum_to_int are
|
||||||
provided for ocaml code to produce and consume these values as
|
provided for ocaml code to produce and consume these values as
|
||||||
integers. Other than that, correct uses of enums will not have
|
integers. Other than that, correct uses of enums will not have
|
||||||
a problem. Since enum labels may overlap between enums, the
|
a problem. Since enum labels may overlap between enums, the
|
||||||
enum_to_int and int_to_enum functions take an enum type label as an
|
enum_to_int and int_to_enum functions take an enum type label as an
|
||||||
argument. Example:
|
argument. Example:
|
||||||
</p>
|
</p>
|
||||||
|
|
@ -435,14 +437,14 @@ type c_enum_tag = [
|
||||||
val int_to_enum c_enum_type -> int -> c_obj
|
val int_to_enum c_enum_type -> int -> c_obj
|
||||||
val enum_to_int c_enum_type -> c_obj -> c_obj
|
val enum_to_int c_enum_type -> c_obj -> c_obj
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
So it's possible to do this:
|
So it's possible to do this:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
bash-2.05a$ ocamlmktop -custom enum_test_wrap.o enum_test.cmo -o enum_test_top
|
bash-2.05a$ ocamlmktop -custom enum_test_wrap.o enum_test.cmo -o enum_test_top
|
||||||
bash-2.05a$ ./enum_test_top
|
bash-2.05a$ ./enum_test_top
|
||||||
Objective Caml version 3.04
|
Objective Caml version 3.04
|
||||||
|
|
@ -455,7 +457,7 @@ val x : Enum_test.c_obj = C_enum `a
|
||||||
# int_to_enum `c_enum_type 4 ;;
|
# int_to_enum `c_enum_type 4 ;;
|
||||||
- : Enum_test.c_obj = C_enum `c
|
- : Enum_test.c_obj = C_enum `c
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<H4><a name="Ocaml_nn11"></a>31.2.2.1 Enum typing in Ocaml</H4>
|
<H4><a name="Ocaml_nn11"></a>31.2.2.1 Enum typing in Ocaml</H4>
|
||||||
|
|
||||||
|
|
@ -577,14 +579,14 @@ void printfloats( float *tab, int len );
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
C++ classes, along with structs and unions are represented by C_obj
|
C++ classes, along with structs and unions are represented by C_obj
|
||||||
(string -> c_obj -> c_obj) wrapped closures. These objects
|
(string -> c_obj -> c_obj) wrapped closures. These objects
|
||||||
contain a method list, and a type, which allow them to be used like
|
contain a method list, and a type, which allow them to be used like
|
||||||
C++ objects. When passed into typemaps that use pointers, they
|
C++ objects. When passed into typemaps that use pointers, they
|
||||||
degrade to pointers through their "&" method. Every method
|
degrade to pointers through their "&" method. Every method
|
||||||
an object has is represented as a string in the object's method table,
|
an object has is represented as a string in the object's method table,
|
||||||
and each method table exists in memory only once. In addition
|
and each method table exists in memory only once. In addition
|
||||||
to any other operators an object might have, certain builtin ones are
|
to any other operators an object might have, certain builtin ones are
|
||||||
provided by SWIG: (all of these take no arguments (C_void))
|
provided by SWIG: (all of these take no arguments (C_void))
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<table summary="SWIG provided operators">
|
<table summary="SWIG provided operators">
|
||||||
|
|
@ -703,7 +705,7 @@ Here's a simple example using Trolltech's Qt Library:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<table border="1" bgcolor="#dddddd" summary="Qt Library example">
|
<table border="1" bgcolor="#dddddd" summary="Qt Library example">
|
||||||
<tr><th><center>qt.i</center></th></tr>
|
<tr><th><center>qt.i</center></th></tr>
|
||||||
<tr><td><pre>
|
<tr><td><pre>
|
||||||
%module qt
|
%module qt
|
||||||
%{
|
%{
|
||||||
|
|
@ -733,7 +735,7 @@ bash-2.05a$ QTPATH=/your/qt/path
|
||||||
bash-2.05a$ for file in swig.mli swig.ml swigp4.ml ; do swig -ocaml -co $file ; done
|
bash-2.05a$ for file in swig.mli swig.ml swigp4.ml ; do swig -ocaml -co $file ; done
|
||||||
bash-2.05a$ ocamlc -c swig.mli ; ocamlc -c swig.ml
|
bash-2.05a$ ocamlc -c swig.mli ; ocamlc -c swig.ml
|
||||||
bash-2.05a$ ocamlc -I `camlp4 -where` -pp "camlp4o pa_extend.cmo q_MLast.cmo" -c swigp4.ml
|
bash-2.05a$ ocamlc -I `camlp4 -where` -pp "camlp4o pa_extend.cmo q_MLast.cmo" -c swigp4.ml
|
||||||
bash-2.05a$ swig -ocaml -c++ -I$QTPATH/include qt.i
|
bash-2.05a$ swig -ocaml -c++ -I$QTPATH/include qt.i
|
||||||
bash-2.05a$ mv qt_wrap.cxx qt_wrap.c
|
bash-2.05a$ mv qt_wrap.cxx qt_wrap.c
|
||||||
bash-2.05a$ ocamlc -c -ccopt -xc++ -ccopt -g -g -ccopt -I$QTPATH/include qt_wrap.c
|
bash-2.05a$ ocamlc -c -ccopt -xc++ -ccopt -g -g -ccopt -I$QTPATH/include qt_wrap.c
|
||||||
bash-2.05a$ ocamlc -c qt.mli
|
bash-2.05a$ ocamlc -c qt.mli
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue