// File : interface.i %module package %include equations.i %include graphics.i %include fileio.i %include data.i %include network.c %include "../Include/user.h"
When used in this manner, SWIG will create a single wrapper file containing all of the included functions.
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 will automatically declare all functions it finds as "extern". Thus, use of a header file may not be required in this case.
%module derived
%extern baseclass.h // Grab definition of a base class
// Now wrap a derived class
class Derived : public BaseClass {
public:
...
};
This approach turns out to be 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
// 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 cool Perl script that you liked to use alot. You could place this in the SWIG library. Now whenever you wanted to use it, you could retrieve it by issuing :
Support files can also be checked out within an interface file using the %checkout directive.unix > swig -perl5 -co myscript.pl myscript.pl checked out from the SWIG library
This will attempt to copy the file myscript.pl to the current directory when SWIG is run. If the file already exists, nothing is done.%checkout myscript.pl
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
and the file `cool.i' will be placed in the Python section of the library. If your interface file is general purpose, you can install it into the general library as follows :unix > swig -ci -python cool.i
When files are checked in, they are placed into the directory defined by the SWIG_LIB variable that was used during SWIG compilation or the SWIG_LIB environment variable (if set). If you don't know what the value of this variable is, type the following to display its location.unix > swig -ci ../cool.i
unix > swig -swiglib /usr/local/lib/swig_lib unix >
In order to check files into the library, you must have write permission on the library directory. For this reason, one of the primary uses for the -ci option is to provide a simple mechanism for installing SWIG extensions. If these extensions need to install library files, that can be done by simply running SWIG.
The module list can contain SWIG generated modules or third-party applications. Refer to the appropriate language chapter for a detailed description of this feature.%module package, equations, graphics, fileio, data, network, user ... More declarations ...