// File : interface.i %module package %include "equations.i" %include "graphics.i" %include "fileio.i" %include "data.i" %include "network.c" %include "../Include/user.h"
In this case, SWIG creates a single wrapper file for a module package that contains all of the included declarations. Repeated %module directives in other files are simply ignored.
The %include directive can process SWIG interface files, C header files, and C source files (provided they are sufficiently clean). When processing a C source file, SWIG automatically declares all functions it finds as "extern". Thus, use of a header file may not be required in this case. Running SWIG on C++ source files is not recommended due to parser limitations
For example, if you wanted to extract some common typedef declarations from a header file, you might write this:
Similarly, if you are working with multiple SWIG modules, you might write the following to pick up C++ base classes. For example:%module foo %import "types.h" ...
If a file included with %import contains a %module directive, it is sometimes used by the target language module to coordinate the operation of more than one SWIG dynamically loaded module. This is an advanced topic that is described in the chapter on the SWIG runtime libraries.%module foo // Grab the base class %import "base.i" // Define a derived class class Foo : public Base { ... };
This is particularly useful for debugging and building extensions to different kinds of languages. When libraries are specified in this manner, they are included after all of the declarations in interface.i have been wrapped. Thus, this does not work if you are trying to include common declarations, typemaps, and other files.# Include a library file at compile time % swig -tcl -lwish.i interface.i
Within each directory, you can also create subdirectories for each target language. If found, SWIG will search these directories first, allowing the creation of language-specific implementations of a particular library file.
You can override the location of the SWIG library by setting the SWIG_LIB environment variable.
In this example, we are including the SWIG pointer library that adds functions for manipulating C pointers. These added functions become part of your module that can be used as needed. For example, we can write a Tcl script like this that involves both the add() function and two functions from the pointer.i library :%module example %include pointer.i // Grab the SWIG pointer library // a+b --> c extern double add(double a, double b, double *c);
set c [ptrcreate double 0] ;# Create a double * for holding the result add 4 3.5 $c ;# Call our C function puts [ptrvalue $c] ;# Print out the result
In this case, the entire file consists of a single code block. This code will be inserted directly into the resulting wrapper file, providing us with the needed Tcl_AppInit() function.// File : tclsh.i %{ #if TCL_MAJOR_VERSION == 7 && TCL_MINOR_VERSION >= 4 int main(int argc, char **argv) { Tcl_Main(argc, argv, Tcl_AppInit); return(0); } #else extern int main(); #endif int Tcl_AppInit(Tcl_Interp *interp){ int SWIG_init(Tcl_Interp *); if (Tcl_Init(interp) == TCL_ERROR) return TCL_ERROR; /* Now initialize our functions */ if (SWIG_init(interp) == TCL_ERROR) return TCL_ERROR; return TCL_OK; } %}
// File : malloc.i %{ #include <malloc.h> %} %typedef unsigned int size_t void *malloc(size_t nbytes); void *realloc(void *ptr, size_t nbytes); void free(void *);
In this case, we have a general purpose library that could be used whenever we needed access to the malloc() functions. Since this interface file is language independent, we can use it anywhere.
./swig_lib/malloc.i ./swig_lib/tcl/tclsh.i
When used in other interface files, this allows us to use malloc.i with any target language while tclsh.i will only be accessible if creating for wrappers for Tcl (ie. when creating a Perl5 module, SWIG will not look in the tcl subdirectory.
It should be noted that language specific libraries can mask general libraries. For example, if you wanted to make a Perl specific modification to malloc.i, you could make a special version and call it ./swig_lib/perl5/malloc.i. When using Perl, you'd get this version, while all other target languages would use the general purpose version.
If the file pointer.i is not in the current directory, SWIG will look it up in the library, generate wrapper code, and place the output in the current directory. This technique can be used to quickly make a module out of a library file regardless of where you are working.unix > swig -python pointer.i
The library file will be placed in the current directory unless a file with the same name already exists (in which case nothing is done).unix > swig -co -python array.i array.i checked out from the SWIG library unix >
The SWIG library is not restricted to interface files. Suppose you had a Perl script that you liked to use a lot. You could place this in the SWIG library. Now whenever you wanted to use it, you could retrieve it by issuing :
unix > swig -perl5 -co myscript.pl myscript.pl checked out from the SWIG library
Similarly, the library also contains Makefiles to build various extensions. For example, if you need a quick Makefile for building Tcl extension, type the following:
During installation, SWIG creates a collection of preconfigured Makefiles for various scripting languages. If you need to make a new module, just check out one of these Makefiles, make a few changes, and you should be ready to compile and extension for your system.unix> swig -tcl -co Makefile Makefile checked out from the SWIG library