jyapayne/swig
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Merge remote-tracking branch 'origin/master' into gsoc2012-scilab

Browse source 
Conflicts:
	Examples/Makefile.in
This commit is contained in:
Sylvestre Ledru 2013-08-06 10:06:31 +02:00
commit 21e17eaa73
795 changed files with 16905 additions and 11792 deletions
Download patch file Download diff file Expand all files Collapse all files

2
.gitattributes vendored Normal file
View file

@ -0,0 +1,2 @@
.gitattributes export-ignore
.gitignore export-ignore

130
.gitignore vendored Normal file
View file

@ -0,0 +1,130 @@
# Compiled Source
*.o
*.class
# Editor files and various other junk
*.sw?
*.bak
# Local PCRE
pcre
*.gz
# C/C++ object files, based on:
# https://github.com/github/gitignore/blob/master/C.gitignore
# https://github.com/github/gitignore/blob/master/C%2B%2B.gitignore
*.slo
*.lo
# C/C++ dynamic libraries, based on:
# https://github.com/github/gitignore/blob/master/C.gitignore
# https://github.com/github/gitignore/blob/master/C%2B%2B.gitignore
*.dll
*.so
*.so.*
*.dylib
# C/C++ static libraries, based on:
# https://github.com/github/gitignore/blob/master/C.gitignore
# https://github.com/github/gitignore/blob/master/C%2B%2B.gitignore
*.lib
*.lai
*.la
*.a
# C/C++ executables, based on:
# https://github.com/github/gitignore/blob/master/C.gitignore
# https://github.com/github/gitignore/blob/master/C%2B%2B.gitignore
*.exe
*.out
*.app
# Generated by autogen.sh
CCache/autom4te.cache/
CCache/config.h.in
CCache/configure
Source/Include/swigconfig.h.in
Source/Include/swigconfig.h.in~
Source/Makefile.in
Tools/config/compile
Tools/config/config.guess
Tools/config/config.sub
Tools/config/depcomp
Tools/config/install-sh
Tools/config/missing
Tools/config/ylwrap
aclocal.m4
autom4te.cache/
configure
# Generated by ./configure
CCache/Makefile
CCache/ccache_swig_config.h
CCache/config.h
CCache/config.log
CCache/config.status
Examples/Makefile
Examples/guile/Makefile
Examples/test-suite/*/Makefile
Examples/xml/Makefile
Lib/ocaml/swigp4.ml
/Makefile
Source/Include/stamp-h1
Source/Include/swigconfig.h
Source/Makefile
.deps
config.log
config.status
preinst-swig
swig.spec
# Build Artifacts
.dirstamp
CCache/ccache-swig
CCache/ccache-swig.1
Source/CParse/parser.c
Source/CParse/parser.h
Source/eswig
swig
# Generated documentation
Doc/Manual/CCache.html
Doc/Manual/SWIGDocumentation.html
Doc/Manual/SWIGDocumentation.pdf
Doc/Manual/*.book
# Test Suite Generated Files
Examples/test-suite/allegrocl/*/
Examples/test-suite/cffi/*/
Examples/test-suite/chicken/*/
Examples/test-suite/clisp/*/
Examples/test-suite/csharp/*/
Examples/test-suite/d/*/
Examples/test-suite/go/*/
Examples/test-suite/guile/*/
Examples/test-suite/java/*/
Examples/test-suite/lua/*/
Examples/test-suite/mzscheme/*/
Examples/test-suite/ocaml/*/
Examples/test-suite/octave/*/
Examples/test-suite/perl5/*/
Examples/test-suite/php/*/
Examples/test-suite/pike/*/
Examples/test-suite/python/*/
Examples/test-suite/r/*/
Examples/test-suite/ruby/*/
Examples/test-suite/tcl/*/
Examples/test-suite/uffi/*/
# Python generated files, based on:
# https://github.com/github/gitignore/blob/master/Python.gitignore
*.py[cod]
*/__pycache__/
/__pycache__/
# C# generated files
*_runme.exe.mdb
*_runme.exe
# Scratch directories
Examples/scratch

11
.project
View file

@ -1,11 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
<name>SWIG</name>
<comment></comment>
<projects>
</projects>
<buildSpec>
</buildSpec>
<natures>
</natures>
</projectDescription>

57
.travis.yml Normal file
View file

@ -0,0 +1,57 @@
language: cpp
compiler:
- clang
- gcc
env:
- SWIGLANG=
matrix:
include:
- compiler: gcc
env: SWIGLANG=csharp
- compiler: gcc
env: SWIGLANG=go
- compiler: gcc
env: SWIGLANG=guile
- compiler: gcc
env: SWIGLANG=java
- compiler: gcc
env: SWIGLANG=lua
- compiler: gcc
env: SWIGLANG=octave SWIGJOBS=-j4
- compiler: gcc
env: SWIGLANG=perl5
- compiler: gcc
env: SWIGLANG=php
- compiler: gcc
env: SWIGLANG=python
- compiler: gcc
env: SWIGLANG=python PY3=1
- compiler: gcc
env: SWIGLANG=ruby
- compiler: gcc
env: SWIGLANG=tcl
allow_failures:
# None
before_install:
- lsb_release -a
- uname -a
- time sudo apt-get -qq install libboost-dev
- if test "$SWIGLANG" = "csharp"; then sudo apt-get -qq install mono-devel; fi
- if test "$SWIGLANG" = "go"; then go env | sed -e 's/^/export /' > goenvsetup && source goenvsetup && rm -f goenvsetup; fi # Until configure.ac is fixed
- if test "$SWIGLANG" = "guile"; then sudo apt-get -qq install guile-2.0-dev; fi
- if test "$SWIGLANG" = "lua"; then sudo apt-get -qq install lua5.1 liblua5.1-dev; fi
- if test "$SWIGLANG" = "octave"; then sudo apt-get -qq install octave3.2 octave3.2-headers; fi
- if test "$SWIGLANG" = "php"; then sudo apt-get install php5-cli php5-dev; fi
- if test "$SWIGLANG" = "python" -a "$PY3"; then sudo apt-get install python3-dev; fi
- if test "$SWIGLANG" = "tcl"; then sudo apt-get -qq install tcl8.4-dev; fi
script:
- ./autogen.sh && ./configure
- make -s $SWIGJOBS
- if test -z "$SWIGLANG"; then make -s check-ccache; fi
- ./swig -version
- if test -n "$SWIGLANG"; then make -s check-$SWIGLANG-version; fi
- if test -n "$SWIGLANG"; then make -k $SWIGJOBS check-$SWIGLANG-examples; fi
- if test -n "$SWIGLANG"; then make -k $SWIGJOBS check-$SWIGLANG-test-suite; fi
branches:
only:
- master

22
ANNOUNCE
View file

@ -1,31 +1,31 @@
*** ANNOUNCE: SWIG 2.0.6 (30 April 2012) ***
*** ANNOUNCE: SWIG 2.0.10 (in progress) ***
http://www.swig.org
We're pleased to announce SWIG-2.0.6, the latest SWIG release.
We're pleased to announce SWIG-2.0.10, the latest SWIG release.
What is SWIG?
=============
SWIG is a software development tool that reads C/C++ header files and
generates the wrapper code needed to make C and C++ code accessible
from other languages including Perl, Python, Tcl, Ruby, PHP, Java,
Scheme (Guile, MzScheme, CHICKEN), D, Ocaml, Lua, Pike, C#, Modula-3,
Octave, R, Common Lisp (CLISP, Allegro CL, CFFI, UFFI). SWIG can also
export its parse tree in the form of XML and Lisp s-expressions. Major
applications of SWIG include generation of scripting language extension
modules, rapid prototyping, testing, and user interface development for
large C/C++ systems.
from other programming languages including Perl, Python, Tcl, Ruby,
PHP, C#, Go, Java, Lua, Scheme (Guile, MzScheme, CHICKEN), D, Ocaml,
Pike, Modula-3, Octave, R, Common Lisp (CLISP, Allegro CL, CFFI, UFFI).
SWIG can also export its parse tree in the form of XML and Lisp
s-expressions. Major applications of SWIG include generation of
scripting language extension modules, rapid prototyping, testing,
and user interface development for large C/C++ systems.
Availability
============
The release is available for download on Sourceforge at
http://prdownloads.sourceforge.net/swig/swig-2.0.6.tar.gz
http://prdownloads.sourceforge.net/swig/swig-2.0.10.tar.gz
A Windows version is also available at
http://prdownloads.sourceforge.net/swig/swigwin-2.0.6.zip
http://prdownloads.sourceforge.net/swig/swigwin-2.0.10.zip
Please report problems with this release to the swig-devel mailing list,
details at http://www.swig.org/mail.html.

3
CCache/ccache.c
View file

@ -712,12 +712,13 @@ static void from_cache(int first)
passfail = retrieve_from_cache(hashname, output_file, hardlink);
}
free(stderr_file);
if (passfail == -1) {
close(fd_stderr);
unlink(stderr_file);
free(stderr_file);
return;
}
free(stderr_file);
}
/* get rid of the intermediate preprocessor file */

2
CCache/ccache.h
View file

@ -159,7 +159,7 @@ int asprintf(char **ptr, const char *format, ...);
int snprintf(char *,size_t ,const char *, ...);
#endif
void cleanup_dir(const char *dir, size_t maxfiles, size_t maxsize);
void cleanup_dir(const char *dir, size_t maxfiles, size_t maxsize, size_t minfiles);
void cleanup_all(const char *dir);
void wipe_all(const char *dir);

28
CCache/cleanup.c
View file

@ -75,21 +75,40 @@ static void traverse_fn(const char *fname, struct stat *st)
/* sort the files we've found and delete the oldest ones until we are
below the thresholds */
static void sort_and_clean(void)
static void sort_and_clean(size_t minfiles)
{
unsigned i;
size_t adjusted_minfiles = minfiles;
if (num_files > 1) {
/* sort in ascending data order */
qsort(files, num_files, sizeof(struct files *),
(COMPAR_FN_T)files_compare);
}
/* ensure newly cached files (minfiles) are kept - instead of matching
the filenames of those newly cached, a faster and simpler approach
assumes these are the most recent in the cache and if any other
cached files have an identical time stamp, they will also be kept -
this approach would not be needed if the cleanup was done at exit. */
if (minfiles != 0 && minfiles < num_files) {
unsigned minfiles_index = num_files - minfiles;
time_t minfiles_time = files[minfiles_index]->mtime;
for (i=1; i<=minfiles_index; i++) {
if (files[minfiles_index-i]->mtime == minfiles_time)
adjusted_minfiles++;
else
break;
}
}
/* delete enough files to bring us below the threshold */
for (i=0;i<num_files; i++) {
if ((size_threshold==0 || total_size < size_threshold) &&
(files_threshold==0 || (num_files-i) < files_threshold)) break;
if (adjusted_minfiles != 0 && num_files-i <= adjusted_minfiles)
break;
if (unlink(files[i]->fname) != 0 && errno != ENOENT) {
fprintf(stderr, "unlink %s - %s\n",
files[i]->fname, strerror(errno));
@ -103,7 +122,7 @@ static void sort_and_clean(void)
}
/* cleanup in one cache subdir */
void cleanup_dir(const char *dir, size_t maxfiles, size_t maxsize)
void cleanup_dir(const char *dir, size_t maxfiles, size_t maxsize, size_t minfiles)
{
unsigned i;
@ -117,7 +136,7 @@ void cleanup_dir(const char *dir, size_t maxfiles, size_t maxsize)
traverse(dir, traverse_fn);
/* clean the cache */
sort_and_clean();
sort_and_clean(minfiles);
stats_set_sizes(dir, total_files, total_size);
@ -151,7 +170,8 @@ void cleanup_all(const char *dir)
cleanup_dir(dname,
counters[STATS_MAXFILES],
counters[STATS_MAXSIZE]);
counters[STATS_MAXSIZE],
0);
free(dname);
free(sfile);
}

0
CCache/configure.in → CCache/configure.ac
View file

3
CCache/stats.c
View file

@ -168,7 +168,8 @@ static void stats_update_size(enum stats stat, size_t size, size_t numfiles)
if (need_cleanup) {
char *p = dirname(stats_file);
cleanup_dir(p, counters[STATS_MAXFILES], counters[STATS_MAXSIZE]);
cleanup_dir(p, counters[STATS_MAXFILES], counters[STATS_MAXSIZE],
numfiles);
free(p);
}
}

4
CCache/test.sh
View file

@ -142,7 +142,7 @@ basetests() {
testname="non-regular"
mkdir testd
$CCACHE_COMPILE -o testd -c test1.c > /dev/null 2>&1
rmdir testd
rm -rf testd
checkstat 'output to a non-regular file' 1
testname="no-input"
@ -315,7 +315,7 @@ swigtests() {
testname="non-regular"
mkdir testd
$CCACHE_COMPILE -o testd -java testswig1.i > /dev/null 2>&1
rmdir testd
rm -rf testd
checkstat 'output to a non-regular file' 1
testname="no-input"

683
CHANGES
View file

@ -3,6 +3,659 @@ SWIG (Simplified Wrapper and Interface Generator)
See the CHANGES.current file for changes in the current version.
See the RELEASENOTES file for a summary of changes in each release.
Version 2.0.10 (27 May 2013)
============================
2013-05-25: wsfulton
[Python] Fix Python 3 inconsistency when negative numbers are passed
where a parameter expects an unsigned C type. An OverFlow error is
now consistently thrown instead of a TypeError.
2013-05-25: Artem Serebriyskiy
SVN Patch ticket #338 - fixes to %attribute macros for template usage
with %arg.
2013-05-19: wsfulton
Fix ccache-swig internal error bug due to premature file cleanup.
Fixes SF bug 1319 which shows up as a failure in the ccache tests on
Debian 64 bit Wheezy, possibly because ENABLE_ZLIB is defined.
This is a corner case which will be hit when the maximum number of files
in the cache is set to be quite low (-F option), resulting in a cache miss.
2013-05-09: kwwette
[Octave] Fix bugs in Octave module loading:
- fix a memory leak in setting of global variables
- install functions only once, to speed up module loads
2013-04-28: gjanssens
[Guile] Updates in guile module:
- Add support for guile 2.0
- Drop support for guile 1.6
- Drop support for generating wrappers using guile's gh interface.
All generated wrappers will use the scm interface from now on.
- Deprecate -gh and -scm options. They are no longer needed.
A warning will be issued when these options are still used.
- Fix all tests and examples to have a successful travis test
2013-04-18: wsfulton
Apply Patch #36 from Jesus Lopez to add support for $descriptor() special variable macro expansion
in fragments. For example:
%fragment("nameDescriptor", "header")
%{
static const char *nameDescriptor = "$descriptor(Name)";
%}
which will generate into the wrapper if the fragment is used:
static const char *nameDescriptor = "SWIGTYPE_Name";
2013-04-18: wsfulton
Fix SF Bug #428 - Syntax error when preprocessor macros are defined inside of enum lists, such as:
typedef enum {
eZero = 0
#define ONE 1
} EFoo;
The macros are silently ignored.
2013-04-17: wsfulton
[C#] Pull patch #34 from BrantKyser to fix smart pointers in conjuction with directors.
2013-04-15: kwwette
[Octave] Fix bugs in output of cleanup code.
- Cleanup code is now written also after the "fail:" label, so it will be called if
a SWIG_exception is raised by the wrapping function, consistent with other modules.
- Octave module now also recognises the "$cleanup" special variable, if needed.
2013-04-08: kwwette
Add -MP option to SWIG for generating phony targets for all dependencies.
- Prevents make from complaining if header files have been deleted before
the dependency file has been updated.
- Modelled on similar option in GCC.
2013-04-09: olly
[PHP] Add missing directorin typemap for char* and char[] which
fixes director_string testcase failure.
2013-04-05: wsfulton
[Ruby] SF Bug #1292 - Runtime fixes for Proc changes in ruby-1.9 when using STL
wrappers that override the default predicate, such as:
%template(Map) std::map<swig::LANGUAGE_OBJ, swig::LANGUAGE_OBJ, swig::BinaryPredicate<> >;
2013-04-05: wsfulton
[Ruby] SF Bug #1159 - Correctly check rb_respond_to call return values to fix some
further 1.9 problems with functors and use of Complex wrappers.
2013-04-02: wsfulton
[Ruby] Runtime fixes for std::complex wrappers for ruby-1.9 - new native Ruby complex numbers are used.
2013-03-30: wsfulton
[Ruby] Fix seg fault when using STL containers of generic Ruby types, GC_VALUE or LANGUAGE_OBJECT,
on exit of the Ruby interpreter. More frequently observed in ruby-1.9.
2013-03-29: wsfulton
[Ruby] Fix delete_if (reject!) for the STL container wrappers which previously would
sometimes seg fault or not work.
2013-03-25: wsfulton
[Python] Fix some undefined behaviour deleting slices in the STL containers.
2013-03-19: wsfulton
[C#, Java, D] Fix seg fault in SWIG using directors when class and virtual method names are
the same except being in different namespaces when the %nspace feature is not being used.
2013-02-19: kwwette
Fix bug in SWIG's handling of qualified (e.g. const) variables of array type. Given the typedef
a(7).q(volatile).double myarray // typedef volatile double[7] myarray;
the type
q(const).myarray // const myarray
becomes
a(7).q(const volatile).double // const volatile double[7]
Previously, SwigType_typedef_resolve() produces the type
q(const).a(7).q(volatile).double // non-sensical type
which would never match %typemap declarations, whose types were parsed correctly.
Add typemap_array_qualifiers.i to the test suite which checks for the correct behaviour.
2013-02-18: wsfulton
Deprecate typedef names used as constructor and destructor names in %extend. The real
class/struct name should be used.
typedef struct tagEStruct {
int ivar;
} EStruct;
%extend tagEStruct {
EStruct() // illegal name, should be tagEStruct()
{
EStruct *s = new EStruct();
s->ivar = ivar0;
return s;
}
~EStruct() // illegal name, should be ~tagEStruct()
{
delete $self;
}
}
For now these trigger a warning:
extend_constructor_destructor.i:107: Warning 522: Use of an illegal constructor name 'EStruct' in
%extend is deprecated, the constructor name should be 'tagEStruct'.
extend_constructor_destructor.i:111: Warning 523: Use of an illegal destructor name 'EStruct' in
%extend is deprecated, the destructor name should be 'tagEStruct'.
These %extend destructor and constructor names were valid up to swig-2.0.4, however swig-2.0.5 ignored
them altogether for C code as reported in SF bug #1306. The old behaviour of using them has been
restored for now, but is officially deprecated. This does not apply to anonymously defined typedef
classes/structs such as:
typedef struct {...} X;
2013-02-17: kwwette
When generating functions provided by %extend, use "(void)" for no-argument functions
instead of "()". This prevents warnings when compiling with "gcc -Wstrict-prototypes".
2013-02-17: kwwette
[Octave] Minor fix to autodoc generation: get the right type for functions returning structs.
2013-02-15: wsfulton
Deprecate typedef names used in %extend that are not the real class/struct name. For example:
typedef struct StructBName {
int myint;
} StructB;
%extend StructB {
void method() {}
}
will now trigger a warning:
swig_extend.i:19: Warning 326: Deprecated %extend name used - the struct name StructBName
should be used instead of the typedef name StructB.
This is only partially working anyway (the %extend only worked if placed after the class
definition).
2013-02-09: wsfulton
[CFFI] Apply patch #22 - Fix missing package before &body
2013-01-29: wsfulton
[Java] Ensure 'javapackage' typemap is used as it stopped working from version 2.0.5.
2013-01-28: wsfulton
[Python] Apply patch SF #334 - Fix default value conversions "TRUE"->True, "FALSE"->False.
2013-01-28: wsfulton
[Java] Apply patch SF #335 - Truly ignore constructors in directors with %ignore.
2013-01-18: Brant Kyser
[Java] Patch #15 - Allow the use of the nspace feature without the -package commandline option.
This works as long and the new jniclasspackage pragma is used to place the JNI intermediate class
into a package and the nspace feature is used to place all exposed types into a package.
2013-01-15: wsfulton
Fix Visual Studio examples to work when SWIG is unzipped into a directory containing spaces.
2013-01-15: wsfulton
[C#] Fix cstype typemap lookup for member variables so that a fully qualified variable name
matches. For example:
%typemap(cstype) bool MVar::mvar "MyBool"
struct MVar {
bool mvar;
};
2013-01-11: Brant Kyser
[Java, C#, D] SF Bug #1299 - Fix generated names for when %nspace is used on
classes with the same name in two different namespaces.
2013-01-11: Vladimir Kalinin
[C#] Add support for csdirectorin 'pre', 'post' and 'terminator' attributes.
2013-01-08: olly
[PHP] Fix to work with a ZTS build of PHP (broken in 2.0.7).
2013-01-07: olly
Fix bashism in configure, introduced in 2.0.9.
2013-01-06: wsfulton
Pull patch #4 from ptomulik to fix SF Bug #1296 - Fix incorrect warning for virtual destructors
in templates, such as:
Warning 521: Illegal destructor name B< A >::~B(). Ignored.
2013-01-05: wsfulton
[Python] Pull patch #3 from ptomulik to fix SF Bug #1295 - standard exceptions as
classes using the SWIG_STD_EXCEPTIONS_AS_CLASSES macro.
2013-01-04: wsfulton
[Java] Pull patch #2 from BrantKyser to fix SF Bug #1283 - fix smart pointers in conjuction
with directors.
2013-01-03: wsfulton
[Java] Pull patch #1 from BrantKyser to fix SF Bug #1278 - fix directors and nspace feature when
multilevel namespaces are used.
Version 2.0.9 (16 December 2012)
================================
2012-12-16: wsfulton
Fix garbage line number / empty file name reporting for some missing
'}' or ')' error messages.
2012-12-15: kkaempf
[Ruby] Apply patch 3530444, Class#methods and Class#constants returns array of
symbols in Ruby 1.9+
2012-12-14: kkaempf
[Ruby] Apply patch 3530439 and finally replace all occurrences of the STR2CSTR() macro
with StringValuePtr(). STR2CSTR was deprecated since years and got removed in Ruby 1.9
2012-12-14: kkaempf
[Ruby] Applied patches #3530442 and 3530443 to adapt compile and runtime include
paths to match Ruby 1.9+
2012-12-14: wsfulton
[CFFI] Fix #3161614 - Some string constants are incorrect
2012-12-13: wsfulton
[CFFI] Fix #3529690 - Fix incorrect constant names.
2012-12-12: drjoe
[R] add fix to finalizer that was missed earlier
2012-12-11: wsfulton
[Python] Apply patch #3590522 - fully qualified package paths for Python 3 even if a module is in the
same package.
2012-12-08: wsfulton
[Python] Bug #3563647 - PyInt_FromSize_t unavailable prior to Python 2.5 for unsigned int types.
2012-12-08: wsfulton
[Perl] Fix bug #3571361 - C++ comment in C wrappers.
2012-12-07: wsfulton
[C#] Apply patch #3571029 which adds missing director support for const unsigned long long &.
2012-11-28: kwwette
[Octave] Simplified module loading: now just the syntax
$ example;
is accepted, which loads functions globally but constants and variables relative to the current scope.
This make module loading behaviour reliably consistent, and reduces problems when loading modules which
depend on other modules which may not have been previously loaded.
2012-11-27: wsfulton
[cffi] Fix junk output when wrapping single character literal constants.
2012-11-17: wsfulton
[Tcl, Modula3] Add missing support for -outdir.
2012-11-17: wsfulton
Fix segfaults when using filename paths greater than 1024 characters in length.
2012-11-14: wsfulton
[ccache-swig] Apply patch #3586392 from Frederik Deweerdt to fix some error cases - incorrectly using
memory after it has been deleted.
2012-11-09: vzeitlin
[Python] Fix overflow when passing values greater than LONG_MAX from Python 3 for parameters with unsigned long C type.
2012-11-09: wsfulton
Fix some feature matching issues for implicit destructors and implicit constructors and implicit
copy constructors added with %copyctor. Previously a feature for these had to be fully qualified
in order to match. Now the following will also match:
%feature("xyz") ~XXX();
struct XXX {};
2012-11-09: wsfulton
Further consistency in named output typemap lookups for implicit constructors and destructors and
implicit copy constructors added with %copyctor. Previously only the fully qualified name was being
used, now the unqualified name will also be used. For example, previously:
example.i:38: Searching for a suitable 'out' typemap for: void Space::More::~More
Looking for: void Space::More::~More
Looking for: void
Now the unqualified name is also used:
example.i:38: Searching for a suitable 'out' typemap for: void Space::More::~More
Looking for: void Space::More::~More
Looking for: void ~More
Looking for: void
2012-11-02: wsfulton
Fix some subtle named output typemap lookup misses, the fully qualified name was not always being
used for variables, for example:
struct Glob {
int MyVar;
};
Previously the search rules (as shown by -debug-tmsearch) for the getter wrapper were:
example.i:44: Searching for a suitable 'out' typemap for: int MyVar
Looking for: int MyVar
Looking for: int
Now the scope is named correctly:
example.i:44: Searching for a suitable 'out' typemap for: int Glob::MyVar
Looking for: int Glob::MyVar
Looking for: int MyVar
Looking for: int
2012-10-26: wsfulton
Fix director typemap searching so that a typemap specified with a name will be correctly matched. Previously
the name was ignored during the typemap search. Applies to the following list of typemaps:
directorout, csdirectorout, cstype, imtype, ctype, ddirectorout, dtype, gotype, jtype, jni, javadirectorout.
2012-10-11: wsfulton
Most of the special variables available for use in %exception are now also available for expansion in
%extend blocks. These are: $name $symname $overname $decl $fulldecl $parentname $parentsymname, see docs
on "Class extension" in SWIGPlus.html. Patch based on submission from Kris Thielemans.
2012-10-10: wsfulton
Additional new special variables in %exception are expanded as follows:
$parentname - The parent class name (if any) for a method.
$parentsymname - The target language parent class name (if any) for a method.
2012-10-08: iant
[Go] Generating Go code now requires using the -intgosize option to
indicate the size of the 'int' type in Go. This is because the
size of the type is changing from Go 1.0 to Go 1.1 for x86_64.
2012-09-14: wsfulton
Add new warning if the empty template instantiation is used as a base class, for example:
template <typename T> class Base {};
%template() Base<int>;
class Derived : public Base<int> {};
gives the following warning instead of silently ignoring the base:
cpp_inherit.i:52: Warning 401: Base class 'Base< int >' has no name as it is an empty template instantiated with '%template()'. Ignored.
cpp_inherit.i:51: Warning 401: The %template directive must be written before 'Base< int >' is used as a base class and be declared with a name.
2012-09-11: wsfulton
[Java] Fix #3535304 - Direct use of a weak global reference in directors
sometimes causing seg faults especially on Android.
2012-09-06: wsfulton
[Java] Fix (char *STRING, size_t LENGTH) typemaps to accept NULL string.
2012-08-26: drjoe
[R] make ExternalReference slot ref to contain reference
2012-08-26: drjoe
[R] fix Examples/Makefile to use C in $(CC) rather than $(CXX)
Version 2.0.8 (20 August 2012)
==============================
2012-08-15: wsfulton
[Perl] Add size_type, value_type, const_reference to the STL containers.
2012-08-15: wsfulton
[Python] Add discard and add methods to std::set wrappers so that pyabc.i can be used ensuring
MutableSet is a valid abstract base class for std::set. As reported by Alexey Sokolov.
Similarly for std::multiset.
2012-08-15: wsfulton
[Python] Fix #3541744 - Missing PyInt_FromSize_t calls for Python 3.
2012-08-13: wsfulton
[Java] Patch from David Baum to add the assumeoverride feature for Java directors to
improve performance when all overridden methods can be assumed to be overridden.
2012-08-05: wsfulton
[Python] #3530021 Fix unused variable warning.
2012-08-05: wsfulton
[C#] Fix #3536360 - Invalid code sometimes being generated for director methods
with many arguments.
2012-08-05: wsfulton
[Perl] #3545877 - Don't undefine bool if defined by C99 stdbool.h - problem using
Perl 5.16 and later.
2012-08-04: wsfulton
Remove incorrect warning (314) about target language keywords which were triggered
by using declarations and using directives. For example 'string' is a keyword in C#:
namespace std { class string; }
using std::string;
2012-07-21: wsfulton
Fix display of pointers in various places on 64 bit systems - only 32 bits were being shown.
2012-07-21: wsfulton
Fix gdb debugger functions 'swigprint' and 'locswigprint' to display to the gdb output window
rather than stdout. This fixes display problems in gdbtui and the ensures the output
appears where expected in other gdb based debuggers such as Eclipse CDT.
2012-07-20: kwwette
[Octave] segfault-on-exit prevention hack now preserves exit status, and uses C99 _Exit().
2012-07-02: wsfulton
Fix Debian bug http://bugs.debian.org/672035, typemap copy failure - regression introduced
in swig-2.0.5:
%include<stl.i>
using std::pair;
%template(StrPair) pair<std::string, std::string>;
2012-07-02: wsfulton
Fix using declarations combined with using directives with forward class declarations so that
types are correctly found in scope for templates. Example:
namespace Outer2 {
namespace Space2 {
template<typename T> class Thing2;
}
}
using namespace Outer2;
using Space2::Thing2;
template<typename T> class Thing2 {};
// STILL BROKEN void useit2(Thing2<int> t) {}
void useit2a(Outer2::Space2::Thing2<int> t) {}
void useit2b(::Outer2::Space2::Thing2<int> t) {}
void useit2c(Space2::Thing2<int> t) {}
namespace Outer2 {
void useit2d(Space2::Thing2<int> t) {}
}
%template(Thing2Int) Thing2<int>;
2012-06-30: wsfulton
Fix template namespace problems for symbols declared with a forward class declarations, such as:
namespace Space1 {
namespace Space2 {
template<typename T> struct YYY;
}
template<typename T> struct Space2::YYY {
T yyy(T h) {
return h;
}
};
void testYYY1(Space1::Space2::YYY<int> yy) {}
void testYYY2(Space2::YYY<int> yy) {}
void testYYY3(::Space1::Space2::YYY<int> yy) {}
}
%template(YYYInt) Space1::Space2::YYY<int>;
2012-06-30: wsfulton
Fix namespace problems for symbols declared with a forward class declarations, such as:
namespace Space1 {
namespace Space2 {
struct XXX;
struct YYY;
}
struct Space2::YYY {};
struct Space1::Space2::XXX {};
void testXXX2(Space2::XXX xx) {}
void testYYY2(Space2::YYY yy) {}
}
where xx and yy were not recognised as the proxy classes XXX and YYY.
2012-06-30: wsfulton
Fix using declarations combined with using directives with forward class declarations so that
types are correctly found in scope.
namespace Outer2 {
namespace Space2 {
class Thing2;
}
}
using namespace Outer2;
using Space2::Thing2;
class Thing2 {};
// None of the methods below correctly used the Thing2 proxy class
void useit2(Thing2 t) {}
void useit2a(Outer2::Space2::Thing2 t) {}
void useit2b(::Outer2::Space2::Thing2 t) {}
void useit2c(Space2::Thing2 t) {}
namespace Outer2 {
void useit2d(Space2::Thing2 t) {}
}
2012-06-25: wsfulton
Fix using declarations combined with using directives so that types are correctly found in scope.
Example:
namespace Outer2 {
namespace Space2 {
class Thing2 {};
}
}
using namespace Outer2; // using directive
using Space2::Thing2; // using declaration
void useit2(Thing2 t) {}
Similarly for templated classes.
2012-05-29: wsfulton
Fix #3529601 - seg fault when a protected method has the "director"
feature but the parent class does not. Also fix similar problems with
the allprotected feature.
2012-05-28: wsfulton
Fix seg fault when attempting to warn about an illegal destructor - #3530055, 3530078 and #3530118.
Version 2.0.7 (26 May 2012)
===========================
2012-05-26: wsfulton
std::string typemap modifications so they can be used with %apply for other string
classes.
2012-05-25: wsfulton
[Lua] Fixes for -external-runtime to work again.
2012-05-22: szager
[python] Disambiguate SWIG_From_unsigned_SS_int and SWIG_From_unsigned_SS_long.
2012-05-18: olly
[PHP] Fix getters for template members. (SF#3428833, SF#3528035)
2012-05-14: wsfulton
Fix some language's std::map wrappers to recognise difference_type, size_type, key_type
and mapped_type.
2012-05-14: kwwette (signed off by xavier98)
[Octave] Prevent Octave from seg-faulting at exit when SWIG
modules are loaded, due to bugs in Octave's cleanup code:
* Wrapping functions now declared with Octave DEFUN_DLD macro,
and loaded through Octave's dynamic module loader
* Global variables of swigref type are now assigned a new()
copy of the swigref class, to prevent double-free errors
* SWIG module at-exit cleanup function now created in Octave
through eval(), so not dependent on loaded .oct library
* For Octave versions 3.1.* to 3.3.*, register C-level at-exit
function which terminates Octave immediately (with correct
status code) without performing memory cleanup. This function
can be controlled with macros in Lib/octave/octruntime.swg
[Octave] New syntax for determing whether SWIG module should be
loaded globally or non-globally. To load module "example" globally,
type the module name
$ example;
as before; to load module non-globally, assign it to a variable:
$ example = example;
or
$ ex = example;
for a shorter (local) module name. -global/-noglobal command-line
options and module command line are deprecated. Added usage info
to module, so typing
$ help example
or incorrect usage should display proper usage, with examples.
*** POTENTIAL INCOMPATIBILITY ***
2012-05-12: olly
[PHP] Fix memory leak in code generated for a callback. Patch from
SF bug #3510806.
2012-05-12: olly
[PHP] Avoid using zend_error_noreturn() as it doesn't work with all
builds of PHP (SF bug #3166423). Instead we now wrap it in a
SWIG_FAIL() function which we annotate as "noreturn" for GCC to
avoids warnings. This also reduces the size of the compiled
wrapper (e.g. the stripped size is reduced by 6% for Xapian's PHP
bindings).
2012-05-11: wsfulton
[Java] SF patch #3522855 Fix unintended uninitialised memory access in OUTPUT typemaps.
2012-05-11: wsfulton
[Java] SF patch #3522674 Fix possible uninitialised memory access in char **STRING_OUT
typemap.
2012-05-11: wsfulton
[Java] SF patch #3522611 Fix uninitialised size regression in char **STRING_ARRAY
introduced in swig-2.0.6.
2012-05-11: wsfulton
SF bug #3525050 - Fix regression introduced in swig-2.0.5 whereby defining one typemap
method such as an 'out' typemap may hide another typemap method such as an 'in' typemap -
only occurs when the type is a template type where the template parameters are the same
via a typedef.
2012-05-10: olly
[PHP] Fix the constant typemaps for SWIGTYPE, etc - previously
these used the wrong name for renamed constants. Add
autodoc_runme.php to the testsuite as a regression test for this.
2012-05-02: ianlancetaylor
[Go] Remove compatibility support for gccgo 4.6. Using
SWIG with gccgo will now require gccgo 4.7. Using SWIG
with the more commonly used gc compiler is unaffected.
2012-05-01: wsfulton
Fix generated code for C forward enum declarations in some languages.
Version 2.0.6 (30 April 2012)
=============================
2012-04-25: wsfulton
[Lua] Fix uninitialised variable in SWIGTYPE **OUTPUT typemaps as reported by Jim Anderson.
2012-04-28: wsfulton
[Python] Fix compilation errors when wrapping STL containers on Mac OSX and possibly other systems.
2012-04-28: wsfulton
[Java] Patch 3521811 from Leo Davis - char **STRING_ARRAY typemaps fixed to handle
null pointers.
Version 2.0.5 (19 April 2012)
=============================
@ -349,7 +1002,7 @@ Version 2.0.5 (19 April 2012)
namespace std {
template<class Key, class T> struct map {
class iterator;
}
};
}
iterator was scoped as std::iterator, but now it is correctly std::map<Key, T>::iterator;
@ -361,10 +1014,10 @@ Version 2.0.5 (19 April 2012)
template<class Key, class T, class C = int> struct Map {
typedef Key key_type;
typedef T mapped_type;
}
};
}
tyepdef double DOUBLE;
%typemap(MM) Std::Map<int, DOUBLE>;
typedef double DOUBLE;
%template(MM) Std::Map<int, DOUBLE>;
All symbols within Map will be resolved correctly, eg key_type and mapped_type no matter if the
wrapped code uses Std::Map<int, double> or std::Map<int, DOUBLE> or Std::Map<int, double, int>
@ -3199,7 +3852,7 @@ Version 1.3.32 (November 15, 2007)
[C#] Added missing support for C++ class member pointers.
08/09/2007: wsfulton
[C#, Java] Add support for $owner in the "out" typemaps like in the the scripting
[C#, Java] Add support for $owner in the "out" typemaps like in the scripting
language modules. Note that $owner has always been supported in the "javaout" / "csout"
typemaps.
@ -3899,7 +4552,7 @@ Version 1.3.30 (November 13, 2006)
10/12/2006: wsfulton
[Java] Remove potential race condition on the proxy class' delete() method
(it is now a synchronized method, but is now customisable by changing the
methodmodifiers attribute in the the javadestruct or javadestruct_derived typemap)
methodmodifiers attribute in the javadestruct or javadestruct_derived typemap)
[C#] Remove potential race condition on the proxy class' Dispose() method,
similar to Java's delete() above.
@ -4707,7 +5360,7 @@ Version 1.3.28 (February 12, 2006)
%naturalvar std::string;
%include <std_string.i>
that will tell swig to use the the 'natural' wrapping
that will tell swig to use the 'natural' wrapping
mechanism to all std::string global and member
variables.
@ -8214,7 +8867,7 @@ Version 1.3.23 (November 11, 2004)
b = B()
b.bar(1)
note the the methods are emitted inside the classes,
note the methods are emitted inside the classes,
and hence, the %template name refers to the 'member'
method name, not a global namespace name.
@ -11728,7 +12381,7 @@ Version 1.3.20 (December 17, 2003)
06/25/2003: mrose (Mark Rose)
[Python] Director typemap marshalling checks for null pointers when
walking the parameter list instead of relying soley on the parameter
count. Cures a segfault that occured for multiple argument inv typemaps.
count. Cures a segfault that occurred for multiple argument inv typemaps.
Someone with more Swig experience should probably review this code.
06/24/2003: mkoeppe (Matthias Koeppe)
@ -16162,7 +16815,7 @@ Version 1.3.12 (June 2, 2002)
%feature, %rename, %ignore, %exception, and related directives:
Namespaces are fully integrated into the the renaming and declaration
Namespaces are fully integrated into the renaming and declaration
matcher. For example:
%rename(display) Foo::print; // Rename in namespace Foo
@ -17203,7 +17856,7 @@ Version 1.3.10 (December 10, 2001)
shadow classes. In early implementations, shadow classes were
merely Python wrappers around typed pointer objects. However,
some users actually wanted to receive the shadow class object in C.
To accomodate this, the dereferencing of the "this" pointer in
To accommodate this, the dereferencing of the "this" pointer in
a shadow class was moved to C as described in CHANGES [8/8/99].
However, the process of returning pointers to Python was still
somewhat problematic. Specifically, shadow classes never worked
@ -19117,7 +19770,7 @@ Version 1.3.6 (July 9, 2001)
[Java] destructor (_delete()) was not aware of %name renaming
[Java] extends baseclass did not know about %name renaming
[Java] extends baseclass did extend even when the baseclass was not known to swig
[Java] sometimes enum-declarations occured before the Java class declaration
[Java] sometimes enum-declarations occurred before the Java class declaration
[Java] unrelated enum initialisations no longer appear in Java class
[Java] if module ends in '_' correct JNI names are now produced
@ -20270,7 +20923,7 @@ Version 1.3 Alpha 1 (February 11, 2000)
names or use %apply to map typemaps to alternate names.
8/8/99 : Handling of the 'this' pointer has been changed in Python shadow
classes. Previously, dereferencing of '.this' occured in the
classes. Previously, dereferencing of '.this' occurred in the
Python shadow class itself. Now, this step occurs in the C
wrappers using the following function:
@ -20827,7 +21480,7 @@ Version 1.1 Patch 1 (August 27, 1997)
Would generate completely bogus code with garbage replacing
the '%d'. Caused by one faulty use of printf (wasn't able to find
any other occurences).
any other occurrences).
7/7/97 : Fixed bug in Python shadow class generation with non-member
functions that are returning more than one value.
@ -20943,7 +21596,7 @@ Version 1.1 (June 24, 1997)
.... later ...
int OldName(int);
Unlike %name, %rename will rename any occurence of the old name.
Unlike %name, %rename will rename any occurrence of the old name.
This applies to functions, variables, class members and so forth.
There is no way to disable %rename once set, but you can change the
name by redeclaring it to something else.

14
CHANGES.current
View file

@ -2,16 +2,6 @@ Below are the changes for the current release.
See the CHANGES file for changes in older releases.
See the RELEASENOTES file for a summary of changes in each release.
Version 2.0.6 (30 April 2012)
=============================
2012-04-25: wsfulton
[Lua] Fix uninitialised variable in SWIGTYPE **OUTPUT typemaps as reported by Jim Anderson.
2012-04-28: wsfulton
[Python] Fix compilation errors when wrapping STL containers on Mac OSX and possibly other systems.
2012-04-28: wsfulton
[Java] Patch 3521811 from Leo Davis - char **STRING_ARRAY typemaps fixed to handle
null pointers.
Version 2.0.11 (in progress)
============================

2
COPYRIGHT
View file

@ -66,7 +66,7 @@ Past contributors include:
James Michael DuPont, Clark McGrew, Dustin Mitchell, Ian Cooke, Catalin Dumitrescu, Baran
Kovuk, Oleg Tolmatcev, Tal Shalif, Lluis Padro, Chris Seatory, Igor Bely, Robin Dunn,
Edward Zimmermann, David Ascher, Dominique Dumont, Pier Giorgio Esposito, Hasan Baran Kovuk,
Klaus Wiederänders
Klaus Wiederänders, Richard Beare, Hans Oesterholt.
(See CHANGES and CHANGES.current and the bug tracker for a more complete list).
Past students:

28
Doc/Devel/engineering.html
View file

@ -25,7 +25,7 @@
<li><a name="i8" href="#8">8. Naming Conventions</a>
<li><a name="i9" href="#9">9. Visibility</a>
<li><a name="i10" href="#10">10. Miscellaneous Coding Guidelines</a>
<li><a name="i11" href="#11">11. SVN Tagging Conventions</a>
<li><a name="i11" href="#11">11. Git Tagging Conventions</a>
</ul>
<a name="1" href="#i1">
@ -119,8 +119,8 @@ are case-insensitive on Windows so this convention will prevent you from inadver
creating two files that differ in case-only.
<p>
Each file should include a short abstract, license information and
a SVN revision tag like this:
Each file should include a short abstract and license information
like this:
<blockquote>
<pre>
@ -137,8 +137,6 @@ a SVN revision tag like this:
* This file defines ...
* ----------------------------------------------------------------------------- */
static char cvs[] = "&#36Id&#36";
#include "swig.h"
/* Declarations */
@ -159,12 +157,6 @@ static int avariable;
</pre>
</blockquote>
The SVN revision tag should be placed into a static string as shown
above mangled with the name of the file.
This adds the revision information to the SWIG executable and
makes it possible to extract version information from a raw binary
(sometimes useful in debugging).
<p>
As a general rule, files start to get unmanageable once they exceed
about 2000 lines. Files larger than this should be broken up into
@ -379,10 +371,10 @@ making your changes.
These are largely covered in the main documentation in the Extending.html file.
<a name="11" href="#i11">
<h2>11. SVN Tagging Conventions</h2>
<h2>11. Git Tagging Conventions</h2>
</a>
Use <tt>svn tag</tt> to declare some set of file revisions as related in some
Use <tt>git tag</tt> to declare some set of file revisions as related in some
symbolic way. This eases reference, retrieval and manipulation of these files
later. At the moment (2001/01/16 14:02:53), the conventions are very simple;
let's hope they stay that way!
@ -390,10 +382,10 @@ let's hope they stay that way!
<p>
There are two types of tags, internal (aka personal) and external.
Internal tags are used by SWIG developers primarily, whereas external
tags are used when communicating with people w/ anonymous svn access.
tags are used when communicating with people w/ anonymous git access.
<ul>
<li> Internal tags should start with the developer name and a hyphen.
<li> External tags should start with "v-".
<li> External tags should start with "rel-".
</ul>
That's all there is to it. Some example tags:
@ -402,10 +394,8 @@ That's all there is to it. Some example tags:
<li> ttn-pre-xml-patch
<li> ttn-post-xml-patch
<li> ttn-going-on-vacation-so-dutifully-tagging-now
<li> v-1-3-a37-fixes-bug-2432
<li> v-1-3-a37-fixes-bug-2433
<li> v-1-3-a37-fixes-bug-2432-again
<li> v-1-3-a37-release
<li> rel-1.3.40
<li> rel-2.0.9
</ul>
<hr>

29
Doc/Devel/internals.html
View file

@ -42,6 +42,7 @@
<li><a name="i7" href="#7">7. Debugging SWIG</a>
<ul>
<li><a name="i7.1" href="#7.1">7.1 Debugging DOH Types The Hard Way</a>
<li><a name="i7.2" href="#7.2">7.2 Debugging DOH memory allocation problems</a>
</ul>
</ul>
@ -1179,6 +1180,34 @@ Either <br>
</ul>
<a name="7.2" href="#i7.2">
<h3>7.2 Debugging DOH memory allocation problems</h3>
</a>
<p>
The DOH objects are reference counted and use pools for memory allocation.
The implementation is in <tt>memory.c</tt>. When there are memory corruption problems,
various memory allocator tools are normally used to diagnose problems. These can be used
on SWIG and can be very useful. However, they won't necessarily find use of stale DOH objects,
that is, DOH objects
that are used after they have been deleted. This is because the DOH memory allocator
grabs a chunk of memory from the C memory allocator and manages the usage internally.
Stale DOH object usage can be checked for by defining <tt>DOH_DEBUG_MEMORY_POOLS</tt> in
<tt>memory.c</tt>. If an attempt to use an object is made after the reference count is
zero, an assertion is triggered instead of quietly re-using the stale object...
</p>
<blockquote>
<pre>
swig: DOH/memory.c:91: DohCheck: Assertion `!DOH_object_already_deleted' failed.
</pre>
</blockquote>
<p>
This can be memory intensive as previously used memory in the pool is not re-used so is
only recommended for diagnosing memory corruption problems.
</p>
<hr>
Copyright (C) 1999-2010 SWIG Development Team.

6
Doc/Manual/Allegrocl.html
View file

@ -1118,7 +1118,7 @@ namespace BAR {
function that returns an object (or pointer/reference) of C/C++
type <tt>X</tt>, the wrapping defun (or defmethod) on the Lisp
side will automatically wrap the pointer returned in an instance
of the apropriate class. This makes it much easier to write and
of the appropriate class. This makes it much easier to write and
debug code than if pointers were passed around as a jumble of
integer values.
</p>
@ -1613,7 +1613,7 @@ opoverload&gt;
<p>
Variable length argument lists are not supported, by default. If
such a function is encountered, a warning will generated to
stderr. Varargs are supported via the SWIG <tt>%vararg</tt>
stderr. Varargs are supported via the SWIG <tt>%varargs</tt>
directive. This directive allows you to specify a (finite)
argument list which will be inserted into the wrapper in place
of the variable length argument indicator. As an example,
@ -1624,7 +1624,7 @@ opoverload&gt;
<p>
See the following section
on <a href="Varargs.html#Varargs">Variable Length arguments</a>
provides examples on how <tt>%vararg</tt> can be used, along
provides examples on how <tt>%varargs</tt> can be used, along
with other ways such functions can be wrapped.
</p>

34
Doc/Manual/Android.html
View file

@ -15,7 +15,9 @@
<li><a href="#Android_examples_intro">Examples introduction</a>
<li><a href="#Android_example_simple">Simple C example</a>
<li><a href="#Android_example_class">C++ class example</a>
<li><a href="#Android_examples_other">Other examples</a>
</ul>
<li><a href="#Android_stl">C++ STL</a>
</ul>
</div>
<!-- INDEX -->
@ -45,7 +47,7 @@ This chapter contains a few Android specific notes and examples.
<p>
The examples require the the <a href="http://developer.android.com/sdk/index.html">Android SDK</a> and <a href="http://developer.android.com/sdk/ndk/index.html">Android NDK</a> which can be installed as per instructions in the links.
The examples require the <a href="http://developer.android.com/sdk/index.html">Android SDK</a> and <a href="http://developer.android.com/sdk/ndk/index.html">Android NDK</a> which can be installed as per instructions in the links.
The Eclipse version is not required for these examples as just the command line tools are used (shown for Linux as the host, but Windows will be very similar, if not identical in most places).
Add the SDK tools and NDK tools to your path and create a directory somewhere for your Android projects (adjust PATH as necessary to where you installed the tools):
</p>
@ -744,6 +746,36 @@ Run the app to see the result of calling the C++ code from Java:
<center><img src="android-class.png" alt="Android screenshot of SwigClass example"></center>
<H3><a name="Android_examples_other"></a>18.2.4 Other examples</H3>
<p>
The Examples/android directory contains further examples which can be run and installed in a similar manner to the previous two examples.
</p>
<p>
Note that the 'extend' example is demonstrates the directors feature.
Normally C++ exception handling and the STL is not available by default in the version of g++ shipped with Android, but this example turns these features on as described in the next section.
</p>
<H2><a name="Android_stl"></a>18.3 C++ STL</H2>
<p>
Should the C++ Standard Template Library (STL) be required, an <tt>Application.mk</tt> file needs to be created
in the same directory as the <tt>Android.mk</tt> directory containing information about the STL to use.
See the NDK documentation in the $NDKROOT/docs folder especially CPLUSPLUS-SUPPORT.html.
Below is an example of the <tt>Application.mk</tt> file to make the STLport static library available for use:
</p>
<div class="code">
<pre>
# File: Application.mk
APP_STL := gnustl_static
</pre>
</div>
</body>
</html>

90
Doc/Manual/CSharp.html
View file

@ -38,6 +38,7 @@
<li><a href="#CSharp_memory_management_objects">Memory management for objects passed to the C++ layer</a>
<li><a href="#CSharp_date_marshalling">Date marshalling using the csin typemap and associated attributes</a>
<li><a href="#CSharp_date_properties">A date example demonstrating marshalling of C# properties</a>
<li><a href="#CSharp_date_pre_post_directors">Date example demonstrating the 'pre' and 'post' typemap attributes for directors</a>
<li><a href="#CSharp_partial_classes">Turning wrapped classes into partial classes</a>
<li><a href="#CSharp_extending_proxy_class">Extending proxy classes with additional C# code</a>
<li><a href="#CSharp_enum_underlying_type">Underlying type for enums</a>
@ -190,6 +191,20 @@ csattributes C# attributes for attaching to proxy classes/enums
</li>
<li>
<p>Additional typemap attributes:</p>
<p>
The "null" attribute in the "out" typemap can be specified to provide a value for <tt>$null</tt> to expand into for wrapped functions that return non-void. Normally the default value of <tt>0</tt> is used.
For example this is needed if you change the return type to void:
</p>
<div class="code"><pre>
%typemap(ctype) Status "void"
%typemap(out, null="") Status { ... }
</pre></div>
</li>
<li>
<p>Feature equivalent names:</p>
<div class="code"><pre>
@ -227,10 +242,12 @@ $jnicall -&gt; $imcall
<p>
Unlike the "javain" typemap, the "csin" typemap does not support the 'pgcpp' attribute as the C# module does not have a premature garbage collection prevention parameter.
The "csin" typemap supports additional optional attributes called 'cshin' and 'terminator'.
The "csdirectorin" typemap supports additional optional attributes called 'terminator'.
The 'cshin' attribute should contain the parameter type and name whenever a <a href="Java.html#Java_constructor_helper_function">constructor helper function</a> is generated due to the 'pre' or 'post' attributes.
The 'terminator' attribute normally just contains a closing brace for when the 'pre' attribute contains an opening brace, such as when a C# <tt>using</tt> or <tt>fixed</tt> block is started.
Note that 'pre', 'post', 'terminator' and 'cshin' attributes are not used for marshalling the property set.
Please see the <a href="#CSharp_date_marshalling">Date marshalling example</a> and <a href="#CSharp_date_properties">Date marshalling of properties example</a> for further understanding of these "csin" applicable attributes.
Please see the <a href="#CSharp_date_pre_post_directors">Date marshalling director example</a> for further understanding of the "csdirectorin" attributes.
</p>
</li>
@ -2040,13 +2057,13 @@ The typemaps to achieve this are shown below.
<div class="code">
<pre>
%typemap(cstype) const CDate&amp; "System.DateTime"
%typemap(cstype) const CDate &amp; "System.DateTime"
%typemap(csin,
pre=" CDate temp$csinput = new CDate($csinput.Year, $csinput.Month, $csinput.Day);"
) const CDate &amp;
"$csclassname.getCPtr(temp$csinput)"
%typemap(cstype) CDate&amp; "out System.DateTime"
%typemap(cstype) CDate &amp; "out System.DateTime"
%typemap(csin,
pre=" CDate temp$csinput = new CDate();",
post=" $csinput = new System.DateTime(temp$csinput.getYear(),"
@ -2257,7 +2274,7 @@ Console.WriteLine("Important date: " + importantDate);
</div>
<p>
When SWIG wraps a variable that is a class/struct/union, it is wrapped using a pointer to the type for the reasons given in <a href="SWIG.html#SWIG_structure_data_members">Stucture data members</a>.
When SWIG wraps a variable that is a class/struct/union, it is wrapped using a pointer to the type for the reasons given in <a href="SWIG.html#SWIG_structure_data_members">Structure data members</a>.
The typemap type required is thus <tt>CDate *</tt>. Given that the previous section already designed <tt>CDate *</tt> typemaps, we'll use those same typemaps plus the 'csvarin' and 'csvarout' typemaps.
<div class="code">
@ -2329,8 +2346,69 @@ Some points to note:
<li>The 'csin' typemap has 'pre', 'post' and 'cshin' attributes, and these are all ignored in the property set. The code in these attributes must instead be replicated within the 'csvarin' typemap. The line creating the <tt>temp$csinput</tt> variable is such an example; it is identical to what is in the 'pre' attribute.
</ul>
<H3><a name="CSharp_date_pre_post_directors"></a>19.8.5 Date example demonstrating the 'pre' and 'post' typemap attributes for directors</H3>
<H3><a name="CSharp_partial_classes"></a>19.8.5 Turning wrapped classes into partial classes</H3>
<p>
The 'pre' and 'post' attributes in the "csdirectorin" typemap act like the attributes of the same name in the "csin" typemap.
For example if we modify the <a href="#CSharp_date_marshalling">Date marshalling example</a> like this:
</p>
<div class="code"><pre>
class CDate {
...
void setYear(int);
void setMonth(int);
void setDay(int);
};
struct Action {
virtual void someCallback(CDate &amp;date);
virtual ~Action();
...
};
</pre></div>
<p>
and declare <tt>%feature ("director")</tt> for the <tt>Action</tt> class, we would have to define additional
marshalling rules for <tt>CDate &amp;</tt> parameter. The typemap may look like this:
</p>
<div class="code"><pre>
%typemap(csdirectorin,
pre="System.DateTime temp$iminput = new System.DateTime();",
post="CDate temp2$iminput = new CDate($iminput, false);\n"
"temp2$iminput.setYear(tempdate.Year);\n"
"temp2$iminput.setMonth(tempdate.Month);\n"
"temp2$iminput.setDay(tempdate.Day);"
) CDate &amp;date "out temp$iminput"
</pre></div>
<p>
The generated proxy class code will then contain the following wrapper for calling user-overloaded <tt>someCallback()</tt>:
</p>
<div class="code"><pre>
...
private void SwigDirectorsomeCallback(IntPtr date) {
System.DateTime tempdate = new System.DateTime();
try {
someCallback(out tempdate);
} finally {
// we create a managed wrapper around the existing C reference, just for convenience
CDate temp2date = new CDate(date, false);
temp2date.setYear(tempdate.Year);
temp2date.setMonth(tempdate.Month);
temp2date.setDay(tempdate.Day);
}
}
...
</pre></div>
<p>
Pay special attention to the memory management issues, using these attributes.
</p>
<H3><a name="CSharp_partial_classes"></a>19.8.6 Turning wrapped classes into partial classes</H3>
<p>
@ -2430,7 +2508,7 @@ demonstrating that the class contains methods calling both unmanaged code - <tt>
The following example is an alternative approach to adding managed code to the generated proxy class.
</p>
<H3><a name="CSharp_extending_proxy_class"></a>19.8.6 Extending proxy classes with additional C# code</H3>
<H3><a name="CSharp_extending_proxy_class"></a>19.8.7 Extending proxy classes with additional C# code</H3>
<p>
@ -2469,7 +2547,7 @@ public class ExtendMe : IDisposable {
</pre>
</div>
<H3><a name="CSharp_enum_underlying_type"></a>19.8.7 Underlying type for enums</H3>
<H3><a name="CSharp_enum_underlying_type"></a>19.8.8 Underlying type for enums</H3>
<P>

20
Doc/Manual/Contents.html
View file

@ -16,13 +16,23 @@
<ul>
<li><a href="Preface.html#Preface_nn2">Introduction</a>
<li><a href="Preface.html#Preface_nn4">SWIG Versions</a>
<li><a href="Preface.html#Preface_license">SWIG License</a>
<li><a href="Preface.html#Preface_nn5">SWIG resources</a>
<li><a href="Preface.html#Preface_nn6">Prerequisites</a>
<li><a href="Preface.html#Preface_nn7">Organization of this manual</a>
<li><a href="Preface.html#Preface_nn8">How to avoid reading the manual</a>
<li><a href="Preface.html#Preface_nn9">Backwards compatibility</a>
<li><a href="Preface.html#Preface_release_notes">Release notes</a>
<li><a href="Preface.html#Preface_nn10">Credits</a>
<li><a href="Preface.html#Preface_nn11">Bug reports</a>
<li><a href="Preface.html#Preface_installation">Installation</a>
<ul>
<li><a href="Preface.html#Preface_windows_installation">Windows installation</a>
<li><a href="Preface.html#Preface_unix_installation">Unix installation</a>
<li><a href="Preface.html#Preface_osx_installation">Macintosh OS X installation</a>
<li><a href="Preface.html#Preface_testing">Testing</a>
<li><a href="Preface.html#Preface_examples">Examples</a>
</ul>
</ul>
</div>
<!-- INDEX -->
@ -645,7 +655,9 @@
<li><a href="Android.html#Android_examples_intro">Examples introduction</a>
<li><a href="Android.html#Android_example_simple">Simple C example</a>
<li><a href="Android.html#Android_example_class">C++ class example</a>
<li><a href="Android.html#Android_examples_other">Other examples</a>
</ul>
<li><a href="Android.html#Android_stl">C++ STL</a>
</ul>
</div>
<!-- INDEX -->
@ -684,6 +696,7 @@
<li><a href="CSharp.html#CSharp_memory_management_objects">Memory management for objects passed to the C++ layer</a>
<li><a href="CSharp.html#CSharp_date_marshalling">Date marshalling using the csin typemap and associated attributes</a>
<li><a href="CSharp.html#CSharp_date_properties">A date example demonstrating marshalling of C# properties</a>
<li><a href="CSharp.html#CSharp_date_pre_post_directors">Date example demonstrating the 'pre' and 'post' typemap attributes for directors</a>
<li><a href="CSharp.html#CSharp_partial_classes">Turning wrapped classes into partial classes</a>
<li><a href="CSharp.html#CSharp_extending_proxy_class">Extending proxy classes with additional C# code</a>
<li><a href="CSharp.html#CSharp_enum_underlying_type">Underlying type for enums</a>
@ -800,8 +813,9 @@
<!-- INDEX -->
<div class="sectiontoc">
<ul>
<li><a href="Guile.html#Guile_nn1">Supported Guile Versions</a>
<li><a href="Guile.html#Guile_nn2">Meaning of "Module"</a>
<li><a href="Guile.html#Guile_nn3">Using the SCM or GH Guile API</a>
<li><a href="Guile.html#Guile_nn3">Old GH Guile API</a>
<li><a href="Guile.html#Guile_nn4">Linkage</a>
<ul>
<li><a href="Guile.html#Guile_nn5">Simple Linkage</a>
@ -814,8 +828,7 @@
<li><a href="Guile.html#Guile_nn11">Typemaps</a>
<li><a href="Guile.html#Guile_nn12">Representation of pointers as smobs</a>
<ul>
<li><a href="Guile.html#Guile_nn13">GH Smobs</a>
<li><a href="Guile.html#Guile_nn14">SCM Smobs</a>
<li><a href="Guile.html#Guile_nn14">Smobs</a>
<li><a href="Guile.html#Guile_nn15">Garbage Collection</a>
</ul>
<li><a href="Guile.html#Guile_nn16">Exception Handling</a>
@ -912,6 +925,7 @@
<li><a href="Java.html#Java_directors_overhead">Overhead and code bloat</a>
<li><a href="Java.html#Java_directors_example">Simple directors example</a>
<li><a href="Java.html#Java_directors_threading">Director threading issues</a>
<li><a href="Java.html#Java_directors_performance">Director performance tuning</a>
</ul>
<li><a href="Java.html#Java_allprotected">Accessing protected members</a>
<li><a href="Java.html#Java_common_customization">Common customization features</a>

19
Doc/Manual/Customization.html
View file

@ -454,6 +454,11 @@ variables are replaced with.
<td>The actual operation to be performed (a function call, method invocation, variable access, etc.)</td>
</tr>
<tr>
<td>$name</td>
<td>The C/C++ symbol name for the function.</td>
</tr>
<tr>
<td>$symname</td>
<td>The symbol name used internally by SWIG</td>
@ -479,6 +484,16 @@ variables are replaced with.
<td>The fully qualified C/C++ declaration of the method being wrapped including the return type</td>
</tr>
<tr>
<td>$parentname</td>
<td>The parent class name (if any) for a method.</td>
</tr>
<tr>
<td>$parentsymname</td>
<td>The target language parent class name (if any) for a method.</td>
</tr>
</table>
<p>
@ -577,9 +592,7 @@ SWIG_NullReferenceError
</pre></div>
<p>
Since the <tt>SWIG_exception()</tt> function is defined at the C-level
it can be used elsewhere in SWIG. This includes typemaps and helper
functions.
The <tt>SWIG_exception()</tt> function can also be used in typemaps.
</p>
<H2><a name="Customization_ownership"></a>11.2 Object ownership and %newobject</H2>

10
Doc/Manual/Extending.html
View file

@ -2975,7 +2975,7 @@ There are a lot of issues to address.
<div class="code">
<pre>
virtual int functionWrapper(Node *n) {
/* get useful atributes */
/* get useful attributes */
String *name = Getattr(n,"sym:name");
SwigType *type = Getattr(n,"type");
ParmList *parms = Getattr(n,"parms");
@ -3101,7 +3101,7 @@ As you can see, most usages are direct.
<dl>
<dt> <b>configure.in</b>
<dt> <b>configure.ac</b>
<dd> This file is processed by
<p>
@ -3536,7 +3536,7 @@ If you wish for a new language module to be distributed with SWIG,
which we encourage for all popular languages, there are a few requirements.
While we appreciate that getting all aspects of a new language working
won't happen at the outset, there are a set of minimum requirements before
a module can be committed into the SVN repository for distribution with future
a module can be committed into the official Github repository for distribution with future
versions of SWIG. The following are really a summary of this whole section with
details being outlined earlier on.
</p>
@ -3551,7 +3551,7 @@ details being outlined earlier on.
a runtime test, see for example <tt>Examples/python/class</tt>.
</li>
<li>
Modify <tt>configure.in</tt>, <tt>Makefile.in</tt> and <tt>Examples/Makefile.in</tt> to run
Modify <tt>configure.ac</tt>, <tt>Makefile.in</tt> and <tt>Examples/Makefile.in</tt> to run
these examples. Please make sure that if the new language is not
installed properly on a box, <tt>make -k check</tt> should still work by
skipping the tests and examples for the new language module.
@ -3578,7 +3578,7 @@ details being outlined earlier on.
</ol>
<p>
Once accepted into SVN, development efforts should concentrate on
Once accepted into the official Git repository, development efforts should concentrate on
getting the entire test-suite to work with plenty of runtime tests.
Runtime tests should be for existing testcases and new test cases
should be added should there be an area not already covered by

27
Doc/Manual/Go.html
View file

@ -93,25 +93,24 @@ swig -go -help
<th>Go specific options</th>
</tr>
<tr>
<td>-intgo-type-size %lt;s%gt;</td>
<td>Set the size for the Go type <tt>int</tt>. This controls the size
that the C/C++ code expects to see. The %lt;s%gt; argument should
be 32 or 64. This option is currently required during the
transition from Go 1.0 to Go 1.1, as the size of <tt>int</tt> on
64-bit x86 systems changes between those releases (from 32 bits to
64 bits). In the future the option may become optional, and SWIG
will assume that the size of <tt>int</tt> is the size of a C
pointer.</td>
</tr>
<tr>
<td>-gccgo</td>
<td>Generate code for gccgo. The default is to generate code for
6g/8g/5g.</td>
</tr>
<tr>
<td>-gccgo-46</td>
<td>Generate code for gccgo 4.6. The default is set by the configure
script. This generates code that does not use some facilities
that are only available in gccgo 4.7 and later.</td>
</tr>
<tr>
<td>-no-gccgo-46</td>
<td>Turn off <code>-gccgo-46</code>, whether set by default or earlier
on the command line.
</tr>
<tr>
<td>-package &lt;name&gt;</td>
<td>Set the name of the Go package to &lt;name&gt;. The default
@ -511,7 +510,7 @@ into Go types.
<p>Because of limitations in the way output arguments are processed in swig,
a function with output arguments will not have multiple return values.
Instead, you must pass a pointer into the C++ function to tell it where to
store the ouput value. In go, you supply a slice in the place of the output
store the output value. In go, you supply a slice in the place of the output
argument.</p>
<p>For example, suppose you were trying to wrap the modf() function in the

184
Doc/Manual/Guile.html
View file

@ -12,8 +12,9 @@
<!-- INDEX -->
<div class="sectiontoc">
<ul>
<li><a href="#Guile_nn1">Supported Guile Versions</a>
<li><a href="#Guile_nn2">Meaning of "Module"</a>
<li><a href="#Guile_nn3">Using the SCM or GH Guile API</a>
<li><a href="#Guile_nn3">Old GH Guile API</a>
<li><a href="#Guile_nn4">Linkage</a>
<ul>
<li><a href="#Guile_nn5">Simple Linkage</a>
@ -26,8 +27,7 @@
<li><a href="#Guile_nn11">Typemaps</a>
<li><a href="#Guile_nn12">Representation of pointers as smobs</a>
<ul>
<li><a href="#Guile_nn13">GH Smobs</a>
<li><a href="#Guile_nn14">SCM Smobs</a>
<li><a href="#Guile_nn14">Smobs</a>
<li><a href="#Guile_nn15">Garbage Collection</a>
</ul>
<li><a href="#Guile_nn16">Exception Handling</a>
@ -47,7 +47,21 @@
<p>
This section details guile-specific support in SWIG.
<H2><a name="Guile_nn2"></a>23.1 Meaning of "Module"</H2>
<H2><a name="Guile_nn1"></a>23.1 Supported Guile Versions</H2>
<p>
SWIG works with Guile versions 1.8.x and 2.0.x. Support for version
1.6.x has been dropped. The last version of SWIG that still works with
Guile version 1.6.x is SWIG 2.0.9.
<p>
Note that starting with guile 2.0, the guile sources can be compiled for
improved performance. This is currently not tested with swig
so your mileage may vary. To be safe set environment variable
GUILE_AUTO_COMPILE to 0 when using swig generated guile code.
<H2><a name="Guile_nn2"></a>23.2 Meaning of "Module"</H2>
<p>
@ -55,55 +69,18 @@ There are three different concepts of "module" involved, defined
separately for SWIG, Guile, and Libtool. To avoid horrible confusion,
we explicitly prefix the context, e.g., "guile-module".
<H2><a name="Guile_nn3"></a>23.2 Using the SCM or GH Guile API</H2>
<H2><a name="Guile_nn3"></a>23.3 Old GH Guile API</H2>
<p>The guile module can currently export wrapper files that use the guile GH interface or the
SCM interface. This is controlled by an argument passed to swig. The "-gh" argument causes swig
to output GH code, and the "-scm" argument causes swig to output SCM code. Right now the "-scm" argument
is the default. The "-scm" wrapper generation assumes a guile version &gt;= 1.6 and has several advantages over
the "-gh" wrapper generation including garbage collection and GOOPS support.
The "-gh" wrapper generation can be used for older versions of guile.
The guile GH wrapper code generation is depreciated and the
SCM interface is the default. The SCM and GH interface differ greatly in how they store
pointers and have completely different run-time code. See below for more info.
<p>The GH interface to guile is deprecated. Read more about why in the
<p>Guile 1.8 and older could be interfaced using two different api's, the SCM
or the GH API. The GH interface to guile is deprecated. Read more about why in the
<a href="http://www.gnu.org/software/guile/docs/docs-1.6/guile-ref/GH.html#GH">Guile manual</a>.
The idea of the GH interface was to provide a high level API that other languages and projects
could adopt. This was a good idea, but didn't pan out well for general development. But for the
specific, minimal uses that the SWIG typemaps put the GH interface to use is ideal for
using a high level API. So even though the GH interface is depreciated, SWIG will continue to use
the GH interface and provide mappings from the GH interface to whatever API we need.
We can maintain this mapping where guile failed because SWIG uses a small subset of all the GH functions
which map easily. All the guile typemaps like typemaps.i and std_vector.i
will continue to use the GH functions to do things like create lists of values, convert strings to
integers, etc. Then every language module will define a mapping between the GH interface and
whatever custom API the language uses. This is currently implemented by the guile module to use
the SCM guile API rather than the GH guile API.
For example, here are some of the current mapping file for the SCM API</p>
<div class="code"><pre>
<p>Support for the guile GH wrapper code generation has been dropped from SWIG. The last
version of SWIG that can still generate guile GH wrapper code is 2.0.9. Please
use that version if you really need the GH wrapper code.
#define gh_append2(a, b) scm_append(scm_listify(a, b, SCM_UNDEFINED))
#define gh_apply(a, b) scm_apply(a, b, SCM_EOL)
#define gh_bool2scm SCM_BOOL
#define gh_boolean_p SCM_BOOLP
#define gh_car SCM_CAR
#define gh_cdr SCM_CDR
#define gh_cons scm_cons
#define gh_double2scm scm_make_real
...
</pre></div>
<p>This file is parsed by SWIG at wrapper generation time, so every reference to a gh_ function is replaced
by a scm_ function in the wrapper file. Thus the gh_ function calls will never be seen in the wrapper;
the wrapper will look exactly like it was generated
for the specific API. Currently only the guile language module has created a mapping policy from gh_ to scm_,
but there is no reason other languages (like mzscheme or chicken) couldn't also use this.
If that happens, there is A LOT less code duplication in the standard typemaps.</p>
<H2><a name="Guile_nn4"></a>23.3 Linkage</H2>
<H2><a name="Guile_nn4"></a>23.4 Linkage</H2>
<p>
@ -111,7 +88,7 @@ Guile support is complicated by a lack of user community cohesiveness,
which manifests in multiple shared-library usage conventions. A set of
policies implementing a usage convention is called a <b>linkage</b>.
<H3><a name="Guile_nn5"></a>23.3.1 Simple Linkage</H3>
<H3><a name="Guile_nn5"></a>23.4.1 Simple Linkage</H3>
<p>
@ -134,7 +111,7 @@ libraries into Guile.</p>
<div class="targetlang">
<pre>
(define-module (my module))
(define my-so (dynamic-link "./example.so"))
(define my-so (dynamic-link "./libexample.so"))
(dynamic-call "SWIG_init" my-so) ; make SWIG bindings
;; Scheme definitions can go here
</pre>
@ -147,7 +124,17 @@ and <code>dynamic-call</code>:
<div class="targetlang">
<pre>
(load-extension "./example.so" "SWIG_init")
(load-extension "./libexample.so" "SWIG_init")
</pre>
</div>
<p>
A more portable approach would be to drop the shared library extension:
</p>
<div class="targetlang">
<pre>
(load-extension "./libexample" "SWIG_init")
</pre>
</div>
@ -190,7 +177,7 @@ information by including a directive like this in the interface file:
<div class="code">
<pre>
%scheme %{ (load-extension "./example.so" "SWIG_init") %}
%scheme %{ (load-extension "./libexample.so" "SWIG_init") %}
</pre>
</div>
@ -206,7 +193,7 @@ placed between the <code>define-module</code> form and the
<code>SWIG_init</code> via a preprocessor define to avoid symbol
clashes. For this case, however, passive linkage is available.
<H3><a name="Guile_nn6"></a>23.3.2 Passive Linkage</H3>
<H3><a name="Guile_nn6"></a>23.4.2 Passive Linkage</H3>
<p>Passive linkage is just like simple linkage, but it generates an
@ -216,12 +203,12 @@ package name (see below).
<p>You should use passive linkage rather than simple linkage when you
are using multiple modules.
<H3><a name="Guile_nn7"></a>23.3.3 Native Guile Module Linkage</H3>
<H3><a name="Guile_nn7"></a>23.4.3 Native Guile Module Linkage</H3>
<p>SWIG can also generate wrapper code that does all the Guile module
declarations on its own if you pass it the <code>-Linkage
module</code> command-line option. This requires Guile 1.5.0 or later.
module</code> command-line option.
<p>The module name is set with the <code>-package</code> and
<code>-module</code> command-line options. Suppose you want to define
@ -244,7 +231,7 @@ shared libraries into Guile; all bindings are automatically put in
newly created Guile modules.
<div class="targetlang">
<pre>
(define my-so (dynamic-link "./foo.so"))
(define my-so (dynamic-link "./libfoo"))
;; create new module and put bindings there:
(dynamic-call "scm_init_my_modules_foo_module" my-so)
</pre>
@ -252,12 +239,12 @@ newly created Guile modules.
Newer Guile versions have a shorthand procedure for this:
<div class="targetlang">
<pre>
(load-extension "./foo.so" "scm_init_my_modules_foo_module")
(load-extension "./libfoo.so" "scm_init_my_modules_foo_module")
</pre>
</div>
</ul>
<H3><a name="Guile_nn8"></a>23.3.4 Old Auto-Loading Guile Module Linkage</H3>
<H3><a name="Guile_nn8"></a>23.4.4 Old Auto-Loading Guile Module Linkage</H3>
<p>Guile used to support an autoloading facility for object-code
@ -283,7 +270,7 @@ option, SWIG generates an exported module initialization function with
an appropriate name.
<H3><a name="Guile_nn9"></a>23.3.5 Hobbit4D Linkage</H3>
<H3><a name="Guile_nn9"></a>23.4.5 Hobbit4D Linkage</H3>
<p>
@ -308,7 +295,7 @@ my/lib/libfoo.so.X.Y.Z and friends. This scheme is still very
experimental; the (hobbit4d link) conventions are not well understood.
</p>
<H2><a name="Guile_nn10"></a>23.4 Underscore Folding</H2>
<H2><a name="Guile_nn10"></a>23.5 Underscore Folding</H2>
<p>
@ -320,7 +307,7 @@ complained so far.
<code>%rename</code> to specify the Guile name of the wrapped
functions and variables (see CHANGES).
<H2><a name="Guile_nn11"></a>23.5 Typemaps</H2>
<H2><a name="Guile_nn11"></a>23.6 Typemaps</H2>
<p>
@ -412,7 +399,7 @@ constant will appear as a scheme variable. See
<a href="Customization.html#Customization_features">Features and the %feature directive</a>
for info on how to apply the %feature.</p>
<H2><a name="Guile_nn12"></a>23.6 Representation of pointers as smobs</H2>
<H2><a name="Guile_nn12"></a>23.7 Representation of pointers as smobs</H2>
<p>
@ -433,7 +420,7 @@ representing the expected pointer type. See also
If the Scheme object passed was not a SWIG smob representing a compatible
pointer, a <code>wrong-type-arg</code> exception is raised.
<H3><a name="Guile_nn13"></a>23.6.1 GH Smobs</H3>
<H3><a name="Guile_nn14"></a>23.7.1 Smobs</H3>
<p>
@ -444,44 +431,19 @@ mangled type name. As Guile allows registering user types, so-called
implemented now. The details will be discussed in the following.
</p>
<p> A smob is a cons cell where the lower half of the CAR contains the smob type
tag, while the upper half of the CAR and the whole CDR are available. Every
module creates its own smob type in the clientdata field of the module. So the
lower 16 bits of the car of the smob store the tag and the upper 16 bits store
the index this type is in the array. We can then, given a smob, find its
swig_type_info struct by using the tag (lower 16 bits of car) to find which
module this type is in (since each tag is unique for the module). Then we use
the upper 16 bits to index into the array of types attached to this module.
Looking up the module from the tag is worst case O(# of modules) but average
case O(1). This is because the modules are stored in a circularly linked list,
and when we start searching the modules for the tag, we start looking with the
module that the function doing the lookup is in. SWIG_Guile_ConvertPtr() takes
as its first argument the swig_module_info * of the calling function, which is
where we start comparing tags. Most types will be looked up in the same module
that created them, so the first module we check will most likely be correct.
Once we have a swig_type_info structure, we loop through the linked list of
casts, using pointer comparisons.</p>
<H3><a name="Guile_nn14"></a>23.6.2 SCM Smobs</H3>
<p>The SCM interface (using the "-scm" argument to swig) uses swigrun.swg.
The whole type system, when it is first initialized, creates two smobs named "swig" and "collected_swig".
<p>The whole type system, when it is first initialized, creates two smobs named "swig" and "collected_swig".
The swig smob is used for non-garbage collected smobs, while the collected_swig smob is used as described
below. Each smob has the same format, which is a double cell created by SCM_NEWSMOB2()
The first word of data is the pointer to the object and the second word of data is the swig_type_info *
structure describing this type. This is a lot easier than the GH interface above because we can store
a pointer to the type info structure right in the type. With the GH interface, there was not enough
room in the smob to store two whole words of data so we needed to store part of the "swig_type_info address"
in the smob tag. If a generated GOOPS module has been loaded, smobs will be wrapped by the corresponding
GOOPS class.</p>
structure describing this type. If a generated GOOPS module has been loaded, smobs will be wrapped by
the corresponding GOOPS class.</p>
<H3><a name="Guile_nn15"></a>23.6.3 Garbage Collection</H3>
<H3><a name="Guile_nn15"></a>23.7.2 Garbage Collection</H3>
<p>Garbage collection is a feature of the new SCM interface, and it is automatically included
if you pass the "-scm" flag to swig. Thus the swig garbage collection support requires guile &gt;1.6.
<p>Garbage collection is a feature of Guile since version 1.6. As SWIG now requires Guile &gt; 1.8,
it is automatically included.
Garbage collection works like this. Every swig_type_info structure stores in its clientdata field a pointer
to the destructor for this type. The destructor is the generated wrapper around the delete function.
So swig still exports a wrapper for the destructor, it just does not call scm_c_define_gsubr() for
@ -491,7 +453,7 @@ is exactly like described in <a href="Customization.html#Customization_ownership
Object ownership and %newobject</a> in the SWIG manual. All typemaps use an $owner var, and
the guile module replaces $owner with 0 or 1 depending on feature:new.</p>
<H2><a name="Guile_nn16"></a>23.7 Exception Handling</H2>
<H2><a name="Guile_nn16"></a>23.8 Exception Handling</H2>
<p>
@ -517,14 +479,13 @@ mapping:
The default when not specified here is to use "swig-error".
See Lib/exception.i for details.
<H2><a name="Guile_nn17"></a>23.8 Procedure documentation</H2>
<H2><a name="Guile_nn17"></a>23.9 Procedure documentation</H2>
<p>If invoked with the command-line option <code>-procdoc
<var>file</var></code>, SWIG creates documentation strings for the
generated wrapper functions, describing the procedure signature and
return value, and writes them to <var>file</var>. You need Guile 1.4
or later to make use of the documentation files.
return value, and writes them to <var>file</var>.
<p>SWIG can generate documentation strings in three formats, which are
selected via the command-line option <code>-procdocformat
@ -553,7 +514,7 @@ like this:
typemap argument <code>doc</code>. See <code>Lib/guile/typemaps.i</code> for
details.
<H2><a name="Guile_nn18"></a>23.9 Procedures with setters</H2>
<H2><a name="Guile_nn18"></a>23.10 Procedures with setters</H2>
<p>For global variables, SWIG creates a single wrapper procedure
@ -581,7 +542,7 @@ struct members, the procedures <code>(<var>struct</var>-<var>member</var>-get
pointer)</code> and <code>(<var>struct-member</var>-set pointer
value)</code> are <em>not</em> generated.
<H2><a name="Guile_nn19"></a>23.10 GOOPS Proxy Classes</H2>
<H2><a name="Guile_nn19"></a>23.11 GOOPS Proxy Classes</H2>
<p>SWIG can also generate classes and generic functions for use with
@ -589,10 +550,7 @@ Guile's Object-Oriented Programming System (GOOPS). GOOPS is a
sophisticated object system in the spirit of the Common Lisp Object
System (CLOS).
<p>GOOPS support is
only available with the new SCM interface (enabled with the
<code>-scm</code> command-line option of SWIG). To enable GOOPS
support, pass the <code>-proxy</code> argument to
<p>To enable GOOPS support, pass the <code>-proxy</code> argument to
swig. This will export the GOOPS wrapper definitions into the
<code><i>module</i>.scm</code> file in the directory specified by -outdir or the
current directory. GOOPS support requires either passive or module linkage.</p>
@ -730,7 +688,7 @@ Notice that &lt;Foo&gt; is used before it is defined. The fix is to just put th
<code>%import "foo.h"</code> before the <code>%inline</code> block.
</p>
<H3><a name="Guile_nn20"></a>23.10.1 Naming Issues</H3>
<H3><a name="Guile_nn20"></a>23.11.1 Naming Issues</H3>
<p>As you can see in the example above, there are potential naming conflicts. The default exported
@ -767,7 +725,7 @@ guile-modules. For example,</p>
(use-modules ((Test) #:renamer (symbol-prefix-proc 'goops:)))
</pre></div>
<H3><a name="Guile_nn21"></a>23.10.2 Linking</H3>
<H3><a name="Guile_nn21"></a>23.11.2 Linking</H3>
<p>The guile-modules generated above all need to be linked together. GOOPS support requires
@ -787,10 +745,10 @@ and might conflict with names from the GOOPS guile-module (see above). Pass the
argument to solve this problem. If the <code>-exportprimitive</code> option is passed to SWIG the
<code>(export ...)</code> code that would be exported into the scmstub file is exported at the bottom
of the generated GOOPS guile-module.
The <code>%goops</code> directive should contain code to load the .so library.
The <code>%goops</code> directive should contain code to load the shared library.
<div class="code"><pre>
%goops %{ (load-extension "./foo.so" "scm_init_my_modules_foo_module") %}
%goops %{ (load-extension "./libfoo.so" "scm_init_my_modules_foo_module") %}
</pre></div>
<p>
@ -802,7 +760,7 @@ Produces the following code at the top of the generated GOOPS guile-module
(define-module (my modules foo))
;; %goops directive goes here
(load-extension "./foo.so" "scm_init_my_modules_foo_module")
(load-extension "./libfoo.so" "scm_init_my_modules_foo_module")
(use-modules (oop goops) (Swig common))
</pre></div>
@ -810,7 +768,7 @@ Produces the following code at the top of the generated GOOPS guile-module
<li><p><b>Passive Linkage with -scmstub</b>: Here, the name of the scmstub file should be
<code>Module-primitive.scm</code> (with <i>primitive</i> replaced with whatever is given with the <code>-primsuffix</code>
argument. The code to load the <code>.so</code> library should be located in the <code>%scheme</code> directive,
argument. The code to load the shared library should be located in the <code>%scheme</code> directive,
which will then be added to the scmstub file.
SWIG will automatically generate the line <code>(use-modules (<i>Package</i> <i>Module-primitive</i>))</code>
into the GOOPS guile-module. So if <i>Module-primitive.scm</i> is on the autoload path for guile, the
@ -818,7 +776,7 @@ into the GOOPS guile-module. So if <i>Module-primitive.scm</i> is on the autolo
whatever code is needed to load the <i>Module-primitive.scm</i> file into guile.</p>
<div class="targetlang"><pre>
%scheme %{ (load-extension "./foo.so" "scm_init_my_modules_foo_module") %}
%scheme %{ (load-extension "./libfoo.so" "scm_init_my_modules_foo_module") %}
// only include the following definition if (my modules foo) cannot
// be loaded automatically
%goops %{
@ -851,7 +809,7 @@ SWIG will also automatically generate the line <code>(use-modules
directive should contain whatever code is needed to get that module loaded into guile.</p>
<div class="code"><pre>
%goops %{ (load-extension "./foo.so" "scm_init_my_modules_foo_module") %}
%goops %{ (load-extension "./libfoo.so" "scm_init_my_modules_foo_module") %}
</pre></div>
<p>
@ -862,7 +820,7 @@ Produces the following code at the top of the generated GOOPS guile-module
(define-module (my modules foo))
;; %goops directive goes here (if any)
(load-extension "./foo.so" "scm_init_my_modules_foo_module")
(load-extension "./libfoo.so" "scm_init_my_modules_foo_module")
(use-modules (oop goops) (Swig common))
(use-modules ((my modules foo-primitive) :renamer (symbol-prefix-proc

75
Doc/Manual/Java.html
View file

@ -86,6 +86,7 @@
<li><a href="#Java_directors_overhead">Overhead and code bloat</a>
<li><a href="#Java_directors_example">Simple directors example</a>
<li><a href="#Java_directors_threading">Director threading issues</a>
<li><a href="#Java_directors_performance">Director performance tuning</a>
</ul>
<li><a href="#Java_allprotected">Accessing protected members</a>
<li><a href="#Java_common_customization">Common customization features</a>
@ -326,12 +327,13 @@ The exact location may vary on your machine, but the above locations are typical
<p>
The JNI code exists in a dynamic module or shared library (DLL on Windows) and gets loaded by the JVM.
To build a shared library file, you need to compile your module in a manner similar to the following (shown for Solaris):</p>
Assuming you have code you need to link to in a file called <tt>example.c</tt>, in order to build a shared library file, you need to compile your module in a manner similar to the following (shown for Solaris):</p>
<div class="code"><pre>
$ swig -java example.i
$ gcc -c example_wrap.c -I/usr/java/include -I/usr/java/include/solaris
$ ld -G example_wrap.o -o libexample.so
$ gcc -c example.c
$ ld -G example_wrap.o example.o -o libexample.so
</pre></div>
<p>
@ -1921,19 +1923,24 @@ The default behaviour described above can be improved via the <a href="SWIGPlus.
Note that it only works for classes, structs, unions and enums declared within a named C++ namespace.
When the nspace feature is used, the C++ namespaces are converted into Java packages of the same name.
Proxy classes are thus declared within a package and this proxy makes numerous calls to the JNI intermediary class which is declared in the unnamed package by default.
As Java does not support types declared in a named package accessing types declared in an unnamed package, the <tt>-package</tt> commandline option described earlier must be used to provide a parent package.
So if SWIG is run using the <tt>-package com.myco</tt> option, a wrapped class, <tt>MyWorld::Material::Color</tt>, can then be accessed as <tt>com.myco.MyWorld.Material.Color</tt>. If you don't specify a package, you will get the following error message:
As Java does not support types declared in a named package accessing types declared in an unnamed package, the <tt>-package</tt> commandline option described earlier generally should be used to provide a parent package.
So if SWIG is run using the <tt>-package com.myco</tt> option, a wrapped class, <tt>MyWorld::Material::Color</tt>, can then be accessed as <tt>com.myco.MyWorld.Material.Color</tt>.
If you don't specify a package, you will get the following warning:
</p>
<div class="shell">
<pre>
example.i:16: Error: The nspace feature used on 'MyWorld::Material::Color' is not supported unless
a package is specified
with -package - Java does not support types declared in a named package accessing types declared
in an unnamed package.
example.i:16: Warning 826: The nspace feature is used on 'MyWorld::Material::Color' without -package. The generated code
may not compile as Java does not support types declared in a named package accessing types declared in an unnamed package.
</pre>
</div>
<p>
If it is undesirable to have a single top level package, the nspace feature may be used without the <tt>-package</tt> commandline option
(and the resulting warning ignored) if all of the types exposed using SWIG are placed in a package using the nspace feature and the
'jniclasspackage' pragma is used to specify a package for the JNI intermediary class.
</p>
<p>
If the resulting use of the nspace feature and hence packages results in a proxy class in one package deriving or using a proxy class from another package,
you will need to open up the visibility for the pointer constructor and <tt>getCPtr</tt> method from the default 'protected' to 'public' with the <tt>SWIG_JAVABODY_PROXY</tt> macro. See <a href="#Java_code_typemaps">Java code typemaps</a>.
@ -2223,6 +2230,9 @@ The intermediary JNI class can be tailored through the use of pragmas, but is no
<tr>
<td>jniclassbase </td> <td>Base class for the intermediary JNI class</td>
</tr>
<tr>
<td>jniclasspackage </td> <td>Package in which to place the intermediary JNI class</td>
</tr>
<tr>
<td>jniclassclassmodifiers </td> <td>Class modifiers and class type for the intermediary JNI class</td>
</tr>
@ -3354,9 +3364,6 @@ The %feature directive can be applied globally, to specific classes, and to spec
// generate directors for all virtual methods in class Foo
%feature("director") Foo;
// generate a director for just Foo::bar()
%feature("director") Foo::bar;
</pre>
</div>
@ -3527,6 +3534,28 @@ Macros can be defined on the commandline when compiling your C++ code, or altern
</pre>
</div>
<H3><a name="Java_directors_performance"></a>24.5.6 Director performance tuning</H3>
<p>
When a new instance of a director (or subclass) is created in Java, the C++ side of the director performs a runtime check per director method to determine if that particular method is overridden in Java or if it should invoke the C++ base implementation directly. Although this makes initialization slightly more expensive, it is generally a good overall tradeoff.
</p>
<p>
However, if all director methods are expected to usually be overridden by Java subclasses, then initialization can be made faster by avoiding these checks via the <tt>assumeoverride</tt> attribute. For example:
</p>
<div class="code">
<pre>
%feature("director", assumeoverride=1) Foo;
</pre>
</div>
<p>
The disadvantage is that invocation of director methods from C++ when Java doesn't actually override the method will require an additional call up into Java and back to C++. As such, this option is only useful when overrides are extremely common and instantiation is frequent enough that its performance is critical.
</p>
<H2><a name="Java_allprotected"></a>24.6 Accessing protected members</H2>
@ -5468,6 +5497,22 @@ interfaces (implements) for Java class: empty default
<p><tt>%typemap(javafinalize)</tt></p>
<div class="indent">
the <tt>finalize()</tt> method (proxy classes only): default calls the <tt>delete()</tt> method
<p>
Note that the default javafinalize typemap must contain the full implementation of the finalize method.
Any customization to this typemap must still declare a java finalize method with the correct signature.
Note also that the name of the generated "delete" method may be affected by <tt>javadestruct</tt> and <tt>javadestruct_derived</tt> typemaps.
Below shows an example modifying the finalizer, assuming the <tt>delete</tt> method has been renamed to <tt>swig_delete</tt>.
</p>
<div class="code"><pre>
%typemap(javafinalize) SWIGTYPE %{
protected void finalize() {
swig_delete(); // renamed to prevent conflict with existing delete method
}
]%
</pre></div>
</div>
<p>
@ -5617,7 +5662,7 @@ to make the method and constructor public:
<p>
The Java directors feature requires the "javadirectorin", "javadirectorout", "directorin" and the "directorout" typemaps in order to work properly.
The "javapackage" typemap is an optional typemap used to identify the Java package path for individual SWIG generated proxy classes.
The "javapackage" typemap is an optional typemap used to identify the Java package path for individual SWIG generated proxy classes used in director methods.
</p>
<p><tt>%typemap(directorin)</tt></p>
@ -5758,6 +5803,7 @@ The target method is the method in the Java proxy class which overrides the virt
<p>
The "javapackage" typemap is optional; it serves to identify a class's Java package.
This typemap should be used in conjunction with classes that are defined outside of the current SWIG interface file.
The typemap is only used if the type is used in a director method, that is, in a virtual method in a director class.
For example:
</p>
@ -5774,7 +5820,7 @@ For example:
class Example {
public:
virtual ~Example();
void ping(Foo *arg1, Bar *arg2);
virtual void ping(Foo *arg1, Bar *arg2);
};
}
</pre>
@ -5799,7 +5845,7 @@ The corrected interface file looks like:
class Example {
public:
virtual ~Example();
void ping(Foo *arg1, Bar *arg2);
virtual void ping(Foo *arg1, Bar *arg2);
};
}
</pre>
@ -7864,4 +7910,3 @@ Many of these have runtime tests in the java subdirectory.
</body>
</html>

13
Doc/Manual/Library.html
View file

@ -66,18 +66,19 @@ Library files are included using the <tt>%include</tt> directive.
When searching for files, directories are searched in the following order:
</p>
<ul>
<ol>
<li>The current directory
<li>Directories specified with the <tt>-I</tt> command line option
<li>.<tt>/swig_lib</tt>
<li>SWIG library install location as reported by <tt>swig -swiglib</tt>, for example <tt>/usr/local/share/swig/1.3.30</tt>
<li>On Windows, a directory <tt>Lib</tt> relative to the location of <tt>swig.exe</tt> is also searched.
</ul>
</ol>
<p>
Within each directory, SWIG first looks for a subdirectory corresponding to a target language (e.g., <tt>python</tt>,
<tt>tcl</tt>, etc.). If found, SWIG will search the language specific directory first. This allows
for language-specific implementations of library files.
Within directories mentioned in points 3-5, SWIG first looks for a subdirectory
corresponding to a target language (e.g., <tt>python</tt>, <tt>tcl</tt>, etc.).
If found, SWIG will search the language specific directory first. This allows
for language-specific implementations of library files.
</p>
<p>
@ -1871,6 +1872,8 @@ Adding the missing <tt>%shared_ptr</tt> macros will fix this:
</pre>
</div>
<b>Note:</b> There is currently no support for <tt>%shared_ptr</tt> and the director feature.
<H2><a name="Library_nn16"></a>8.5 Utility Libraries</H2>

4
Doc/Manual/Lua.html
View file

@ -236,7 +236,7 @@ More information on building and configuring eLua can be found here: <a href="ht
<p>
Most, but not all platforms support the dynamic loading of modules (Windows &amp; Linux do). Refer to the Lua manual to determine if your platform supports it. For compiling a dynamically loaded module the same wrapper can be used. The commands will be something like this:
Most, but not all platforms support the dynamic loading of modules (Windows &amp; Linux do). Refer to the Lua manual to determine if your platform supports it. For compiling a dynamically loaded module the same wrapper can be used. Assuming you have code you need to link to in a file called <tt>example.c</tt>, the commands will be something like this:
</p>
<div class="shell"><pre>
$ swig -lua example.i -o example_wrap.c
@ -1359,7 +1359,7 @@ extern void sort_double(double* arr, int len);
to create an array in C/C++ then this can be filled within Lua and passed into the function. It works, but it's a bit tedious.
More details can be found in the <a href="Library.html#Library_carrays">carrays.i</a> documentation.</p>
<p>The second and more intuitive way, would be to pass a Lua table directly into the function, and have SWIG automatically convert between Lua-table and C-array. Within the <tt>&lt;typemaps.i&gt;</tt> file there are typemaps ready written to perform this task. To use them is again a matter of using %appy in the correct manner.</p>
<p>The second and more intuitive way, would be to pass a Lua table directly into the function, and have SWIG automatically convert between Lua-table and C-array. Within the <tt>&lt;typemaps.i&gt;</tt> file there are typemaps ready written to perform this task. To use them is again a matter of using %apply in the correct manner.</p>
<p>The wrapper file below, shows both the use of carrays as well as the use of the typemap to wrap arrays. </p>

2
Doc/Manual/Ocaml.html
View file

@ -126,7 +126,7 @@ the resulting .ml and .mli files as well, and do the final link with -custom
<p>
The O'Caml SWIG module now requires you to compile a module (<tt>Swig</tt>)
The OCaml SWIG module now requires you to compile a module (<tt>Swig</tt>)
separately. In addition to aggregating common SWIG functionality, the Swig
module contains the data structure that represents C/C++ values. This allows
easier data sharing between modules if two or more are combined, because

158
Doc/Manual/Octave.html
View file

@ -63,7 +63,7 @@ The SWIG implemention was first based on Octave 2.9.12, so this is the minimum v
</p>
<p>
As of SWIG 2.0.5, the Octave module should work with Octave versions 3.0.5, 3.2.4, and 3.4.0.
As of SWIG 2.0.7, the Octave module has been tested with Octave versions 3.0.5, 3.2.4, 3.4.3, and 3.6.1.
</p>
<H2><a name="Octave_nn3"></a>30.2 Running SWIG</H2>
@ -74,7 +74,7 @@ Let's start with a very simple SWIG interface file, example.i:
</p>
<div class="code"><pre>
%module example
%module swigexample
%{
#include "example.h"
%}
@ -95,7 +95,7 @@ The <tt>-c++</tt> option is also required when wrapping C++ code:
<div class="shell"><pre>$ swig -octave -c++ -o example_wrap.cpp example.i </pre></div>
<p>
This creates a C++ source file <tt>example_wrap.cpp</tt>. A C++ file is generated even when wrapping C code as Octave is itself written in C++ and requires wrapper code to be in the same language. The generated C++ source file contains the low-level wrappers that need to be compiled and linked with the rest of your C/C++ application (in this case, the gcd implementation) to create an extension module.
This creates a C++ source file "example_wrap.cpp". A C++ file is generated even when wrapping C code as Octave is itself written in C++ and requires wrapper code to be in the same language. The generated C++ source file contains the low-level wrappers that need to be compiled and linked with the rest of your C/C++ application (in this case, the gcd implementation) to create an extension module.
</p>
<H3><a name="Octave_nn4"></a>30.2.1 Command-line options</H3>
@ -110,15 +110,12 @@ Options specific to the Octave module are:
<pre>$ swig -octave -help
...
Octave Options (available with -octave)
-global - Load all symbols into the global namespace [default]
-globals <em>name</em> - Set <em>name</em> used to access C global variables [default: 'cvar']
- Use '.' to load C global variables into module namespace
-noglobal - Do not load all symbols into the global namespace
Use '.' to load C global variables into module namespace
-opprefix <em>str</em> - Prefix <em>str</em> for global operator functions [default: 'op_']
</pre></div>
<p>
The <em>-global</em> and <em>-noglobal</em> options determine whether the Octave module will load all symbols into the global namespace in addition to the global namespace.
The <em>-globals</em> option sets the name of the variable which is the namespace for C global variables exported by the module.
The special name "." loads C global variables into the module namespace, i.e. alongside C functions and structs exported by the module.
The <em>-opprefix</em> options sets the prefix of the names of global/friend <a href="#Octave_nn18">operator</a> functions.
@ -138,7 +135,7 @@ $ mkoctfile example_wrap.cpp example.c
</pre></div>
<p>
where example.c is the file containing the gcd() implementation.
where "example.c" is the file containing the gcd() implementation.
</p>
<p>
@ -146,10 +143,10 @@ $ mkoctfile example_wrap.cpp example.c
</p>
<p>
mkoctfile will produce example.oct, which contains the compiled extension module. Loading it into Octave is then a matter of invoking
mkoctfile will produce "swigexample.oct", which contains the compiled extension module. Loading it into Octave is then a matter of invoking
</p>
<div class="targetlang"><pre>octave:1&gt; example</pre></div>
<div class="targetlang"><pre>octave:1&gt; swigexample</pre></div>
<H3><a name="Octave_nn6"></a>30.2.3 Using your module</H3>
@ -160,13 +157,13 @@ Assuming all goes well, you will be able to do this:
</p>
<div class="targetlang"><pre>$ octave -q
octave:1&gt; example
octave:2&gt; example.gcd(4,6)
octave:1&gt; swigexample
octave:2&gt; swigexample.gcd(4,6)
ans = 2
octave:3&gt; example.cvar.Foo
octave:3&gt; swigexample.cvar.Foo
ans = 3
octave:4&gt; example.cvar.Foo=4;
octave:5&gt; example.cvar.Foo
octave:4&gt; swigexample.cvar.Foo=4;
octave:5&gt; swigexample.cvar.Foo
ans = 4 </pre></div>
<H2><a name="Octave_nn7"></a>30.3 A tour of basic C/C++ wrapping</H2>
@ -176,59 +173,26 @@ ans = 4 </pre></div>
<p>
The SWIG module directive specifies the name of the Octave module. If you specify `module example', then in Octave everything in the module will be accessible under "example", as in the above example. When choosing a module name, make sure you don't use the same name as a built-in Octave command or standard module name.
The SWIG module directive specifies the name of the Octave module. If you specify "module swigexample", then in Octave everything in the module will be accessible under "swigexample", as in the above example. When choosing a module name, make sure you don't use the same name as a built-in Octave command or standard module name.
</p>
<p>
When Octave is asked to invoke <tt>example</tt>, it will try to find the .m or .oct file that defines the function "example". It will thusly find example.oct, that upon loading will register all of the module's symbols.
When Octave is asked to invoke <tt>swigexample</tt>, it will try to find the ".m" or ".oct" file that defines the function "swigexample". You therefore need to make sure that "swigexample.oct" is in Octave's search path, which can be specified with the environment variable "OCTAVE_PATH".
</p>
<p>
An Octave module takes three options, <em>-global</em>, <em>-noglobal</em>, and <em>-globals</em>, which behave the same as the corresponding swig <a href="#Octave_nn4">command-line options</a>.
Here are some example usages:
To load an Octave module, simply type its name:
</p>
<div class="targetlang"><pre>
octave:1&gt; example -help
usage: example [-global|-noglobal] [-globals &lt;name&gt;]
octave:2&gt; example -global
octave:3&gt; gcd(4,6)
<div class="targetlang"><pre>
octave:1&gt; swigexample;
octave:2&gt; gcd(4,6)
ans = 2
octave:4&gt; cvar.Foo
ans = 3
octave:5&gt; cvar.Foo=4;
octave:6&gt; cvar.Foo
ans = 4
</pre></div>
<br>
<div class="targetlang"><pre>
octave:1&gt; example -noglobal
octave:2&gt; gcd(6,9)
ans = 3
octave:3&gt; cvar.Foo
error: `cvar' undefined near line 3 column 1
octave:3&gt; example.cvar.Foo
ans = 3
</pre></div>
<br>
<div class="targetlang"><pre>
octave:1&gt; example -globals mycvar
octave:2&gt; cvar.Foo
error: `cvar' undefined near line 2 column 1
octave:2&gt; mycvar.Foo
ans = 3
</pre></div>
<p>
It is also possible to rename the module / global variables namespaces with an assignment, as in: <br>
<div class="targetlang"><pre>
octave:1&gt; example
octave:2&gt; c=example;
octave:3&gt; c.gcd(10,4)
ans = 2
octave:4&gt; some_vars = cvar;
octave:5&gt; some_vars.Foo
ans = 3
octave:4&gt; cvar.Foo=4;
octave:5&gt; cvar.Foo
ans = 4
</pre></div>
<p>
@ -238,15 +202,15 @@ If the module is also used in the base context, however, it must first be loaded
<div class="targetlang"><pre>
octave:1&gt; function l = my_lcm(a,b)
&gt; example
&gt; l = abs(a*b)/example.gcd(a,b);
&gt; swigexample
&gt; l = abs(a*b)/swigexample.gcd(a,b);
&gt; endfunction
octave:2&gt; my_lcm(4,6)
ans = 12
octave:3&gt; example.gcd(4,6)
octave:3&gt; swigexample.gcd(4,6)
error: can't perform indexing operations for &lt;unknown type&gt; type
octave:3&gt; example;
octave:4&gt; example.gcd(4,6)
octave:3&gt; swigexample;
octave:4&gt; swigexample.gcd(4,6)
ans = 2
</pre></div>
@ -257,14 +221,14 @@ ans = 2
Global functions are wrapped as new Octave built-in functions. For example,
</p>
<div class="code"><pre>&#037;module example
<div class="code"><pre>&#037;module swigexample
int fact(int n); </pre></div>
<p>
creates a built-in function <tt>example.fact(n)</tt> that works exactly like you think it does:
creates a built-in function <tt>swigexample.fact(n)</tt> that works exactly like you think it does:
</p>
<div class="targetlang"><pre>octave:1&gt; example.fact(4)
<div class="targetlang"><pre>octave:1&gt; swigexample.fact(4)
24 </pre></div>
<H3><a name="Octave_nn10"></a>30.3.3 Global variables</H3>
@ -274,28 +238,28 @@ int fact(int n); </pre></div>
Global variables are a little special in Octave. Given a global variable:
</p>
<div class="code"><pre>%module example
<div class="code"><pre>%module swigexample
extern double Foo;
</pre></div>
</pre></div>
<p>
To expose variables, SWIG actually generates two functions, to get and set the value. In this case, Foo_set and Foo_set would be generated. SWIG then automatically calls these functions when you get and set the variable-- in the former case creating a local copy in the interpreter of the C variables, and in the latter case copying an interpreter variables onto the C variable.
</p>
<div class="targetlang"><pre>octave:1&gt; example;
octave:2&gt; c=example.cvar.Foo
<div class="targetlang"><pre>octave:1&gt; swigexample;
octave:2&gt; c=swigexample.cvar.Foo
c = 3
octave:3&gt; example.cvar.Foo=4;
octave:3&gt; swigexample.cvar.Foo=4;
octave:4&gt; c
c = 3
octave:5&gt; example.cvar.Foo
octave:5&gt; swigexample.cvar.Foo
ans = 4</pre></div>
<p>
If a variable is marked with the %immutable directive then any attempts to set this variable will cause an Octave error. Given a global variable:
</p>
<div class="code"><pre>%module example
<div class="code"><pre>%module swigexample
%immutable;
extern double Foo;
%mutable;
@ -305,8 +269,8 @@ extern double Foo;
SWIG will allow the reading of <tt>Foo</tt> but when a set attempt is made, an error function will be called.
</p>
<div class="targetlang"><pre>octave:1&gt; example
octave:2&gt; example.Foo=4
<div class="targetlang"><pre>octave:1&gt; swigexample
octave:2&gt; swigexample.Foo=4
error: attempt to set immutable member variable
error: assignment failed, or no method for `swig_type = scalar'
error: evaluating assignment expression near line 2, column 12 </pre></div>
@ -315,9 +279,9 @@ error: evaluating assignment expression near line 2, column 12 </pre></div>
It is possible to add new functions or variables to the module. This also allows the user to rename/remove existing functions and constants (but not linked variables, mutable or immutable). Therefore users are recommended to be careful when doing so.
</p>
<div class="targetlang"><pre>octave:1&gt; example;
octave:2&gt; example.PI=3.142;
octave:3&gt; example.PI
<div class="targetlang"><pre>octave:1&gt; swigexample;
octave:2&gt; swigexample.PI=3.142;
octave:3&gt; swigexample.PI
ans = 3.1420 </pre></div>
<H3><a name="Octave_nn11"></a>30.3.4 Constants and enums</H3>
@ -327,7 +291,7 @@ ans = 3.1420 </pre></div>
Because Octave doesn't really have the concept of constants, C/C++ constants are not really constant in Octave. They are actually just a copy of the value into the Octave interpreter. Therefore they can be changed just as any other value. For example given some constants:
</p>
<div class="code"><pre>%module example
<div class="code"><pre>%module swigexample
%constant int ICONST=42;
#define SCONST "Hello World"
enum Days{SUNDAY,MONDAY,TUESDAY,WEDNESDAY,THURSDAY,FRIDAY,SATURDAY};
@ -337,9 +301,9 @@ enum Days{SUNDAY,MONDAY,TUESDAY,WEDNESDAY,THURSDAY,FRIDAY,SATURDAY};
This is 'effectively' converted into the following Octave code:
</p>
<div class="targetlang"><pre>example.ICONST=42
example.SCONST="Hello World"
example.SUNDAY=0
<div class="targetlang"><pre>swigexample.ICONST=42
swigexample.SCONST="Hello World"
swigexample.SUNDAY=0
.... </pre></div>
<H3><a name="Octave_nn12"></a>30.3.5 Pointers</H3>
@ -350,7 +314,7 @@ example.SUNDAY=0
C/C++ pointers are fully supported by SWIG. Furthermore, SWIG has no problem working with incomplete type information. Given a wrapping of the &lt;file.h&gt; interface:
</p>
<div class="code"><pre>%module example
<div class="code"><pre>%module swigexample
FILE *fopen(const char *filename, const char *mode);
int fputs(const char *, FILE *);
int fclose(FILE *);
@ -361,18 +325,18 @@ When wrapped, you will be able to use the functions in a natural way from Octave
</p>
<div class="targetlang"><pre>
octave:1&gt; example;
octave:2&gt; f=example.fopen("w","junk");
octave:3&gt; example.fputs("Hello world",f);
octave:4&gt; example.fclose(f);
octave:1&gt; swigexample;
octave:2&gt; f=swigexample.fopen("w","junk");
octave:3&gt; swigexample.fputs("Hello world",f);
octave:4&gt; swigexample.fclose(f);
</pre></div>
<p>
Simply printing the value of a wrapped C++ type will print it's typename. E.g.,
</p>
<div class="targetlang"><pre>octave:1&gt; example;
octave:2&gt; f=example.fopen("junk","w");
<div class="targetlang"><pre>octave:1&gt; swigexample;
octave:2&gt; f=swigexample.fopen("junk","w");
octave:3&gt; f
f =
@ -384,8 +348,8 @@ f =
As the user of the pointer, you are responsible for freeing it, or closing any resources associated with it (just as you would in a C program). This does not apply so strictly to classes and structs (see below).
</p>
<div class="targetlang"><pre>octave:1&gt; example;
octave:2&gt; f=example.fopen("not there","r");
<div class="targetlang"><pre>octave:1&gt; swigexample;
octave:2&gt; f=swigexample.fopen("not there","r");
error: value on right hand side of assignment is undefined
error: evaluating assignment expression near line 2, column 2 </pre></div>
@ -407,8 +371,8 @@ For each wrapped structure and class, a <tt>swig_ref</tt> will be exposed that h
</p>
<div class="targetlang">
<pre>octave:1&gt; example;
octave:2&gt; p=example.Point();
<pre>octave:1&gt; swigexample;
octave:2&gt; p=swigexample.Point();
octave:3&gt; p.x=3;
octave:4&gt; p.y=5;
octave:5&gt; p.x, p.y
@ -442,9 +406,9 @@ public:
can be used from Octave like this
</p>
<div class="targetlang">
<pre>octave:1&gt; example;
octave:2&gt; p1=example.Point(3,5);
octave:3&gt; p2=example.Point(1,2);
<pre>octave:1&gt; swigexample;
octave:2&gt; p1=swigexample.Point(3,5);
octave:3&gt; p2=swigexample.Point(1,2);
octave:4&gt; p1.distance(p2)
ans = 3.6056
</pre></div>
@ -685,7 +649,7 @@ C++ class and function templates are fully supported as in other modules, in tha
For example, function templates can be instantiated as follows:
</p>
<div class="code"><pre>%module example
<div class="code"><pre>%module swigexample
%inline {
template&lt;class __scalar&gt;
__scalar mul(__scalar a,__scalar b) {
@ -713,7 +677,7 @@ ans = 22 + 46i
Similarly, class templates can be instantiated as in the following example,
</p>
<div class="code"><pre>%module example
<div class="code"><pre>%module swigexample
%include &lt;std_complex.i&gt;
%include &lt;std_string.i&gt;
%inline {

4
Doc/Manual/Perl5.html
View file

@ -170,8 +170,8 @@ $ perl -e 'use Config; print "$Config{archlib}\n";'
<p>
The preferred approach to building an extension module is to compile it into
a shared object file or DLL. To do this, you will need to compile your program
using commands like this (shown for Linux):
a shared object file or DLL. Assuming you have code you need to link to in a file called <tt>example.c</tt>,
you will need to compile your program using commands like this (shown for Linux):
</p>
<div class="code"><pre>

19
Doc/Manual/Php.html
View file

@ -146,7 +146,7 @@ least work for Linux though):
<p>
To test the extension from a PHP script, you need to load it first. You
can load it for every script by adding this line the <tt>[PHP]</tt> section of
can load it for every script by adding this line to the <tt>[PHP]</tt> section of
<tt>php.ini</tt>:
</p>
@ -156,7 +156,7 @@ can load it for every script by adding this line the <tt>[PHP]</tt> section of
<p>
Alternatively, you can load it explicitly only for scripts which need it
by adding this line:
by adding this line to the start of each such PHP script::
</p>
<div class="code"><pre>
@ -164,7 +164,7 @@ by adding this line:
</pre></div>
<p>
to the start of each PHP file. SWIG also generates a php module, which
SWIG also generates a php module, which
attempts to do the <tt>dl()</tt> call for you:
</p>
@ -506,6 +506,12 @@ this, one needs to include <b>phppointers.i</b> which defines the
named typemap REFERENCE.
</p>
<p>
However, this relies on call-time pass-by-reference, which has been
deprecated in PHP for some time, and was finally <b>removed in PHP 5.4</b>.
So you should avoid creating new wrappers which rely on this approach.
</p>
<div class="code"><pre>
%module example
%include "phppointers.i"
@ -705,7 +711,7 @@ would be accessed in PHP as,
<div class="code"><pre>
include("example.php");
echo "There has now been " . Ko::threats() . " threats\n";
echo "There have now been " . Ko::threats() . " threats\n";
</pre></div>
@ -718,7 +724,7 @@ function, e.g.
Ko::threats(10);
echo "There has now been " . Ko::threats() . " threats\n";
echo "There have now been " . Ko::threats() . " threats\n";
</pre></div>
<H4><a name="Php_nn2_6_4"></a>32.2.6.4 Static Member Functions</H4>
@ -895,9 +901,6 @@ globally, to specific classes, and to specific methods, like this:
// generate directors for all virtual methods in class Foo
%feature("director") Foo;
// generate a director for just Foo::bar()
%feature("director") Foo::bar;
</pre>
</div>

256
Doc/Manual/Preface.html
View file

@ -12,13 +12,23 @@
<ul>
<li><a href="#Preface_nn2">Introduction</a>
<li><a href="#Preface_nn4">SWIG Versions</a>
<li><a href="#Preface_license">SWIG License</a>
<li><a href="#Preface_nn5">SWIG resources</a>
<li><a href="#Preface_nn6">Prerequisites</a>
<li><a href="#Preface_nn7">Organization of this manual</a>
<li><a href="#Preface_nn8">How to avoid reading the manual</a>
<li><a href="#Preface_nn9">Backwards compatibility</a>
<li><a href="#Preface_release_notes">Release notes</a>
<li><a href="#Preface_nn10">Credits</a>
<li><a href="#Preface_nn11">Bug reports</a>
<li><a href="#Preface_installation">Installation</a>
<ul>
<li><a href="#Preface_windows_installation">Windows installation</a>
<li><a href="#Preface_unix_installation">Unix installation</a>
<li><a href="#Preface_osx_installation">Macintosh OS X installation</a>
<li><a href="#Preface_testing">Testing</a>
<li><a href="#Preface_examples">Examples</a>
</ul>
</ul>
</div>
<!-- INDEX -->
@ -57,13 +67,26 @@ In the late 1990's, the most stable version of SWIG was release
over a period of 10 years starting from the year 2000. The final version in the 1.3.x
series was 1.3.40, but in truth the 1.3.x series had been stable for many years.
An official stable version was released along with the decision to make SWIG
license changes and this gave rise to version 2.0.0 in 2010. The license was clarified
license changes and this gave rise to version 2.0.0 in 2010.
</p>
<H2><a name="Preface_license"></a>1.3 SWIG License</H2>
<p>
The LICENSE file shipped with SWIG in the top level directory contains the SWIG license.
For further insight into the license including the license of SWIG's output code, please visit
the SWIG legal page - <a href="http://www.swig.org/legal.html">http://www.swig.org/legal.html</a>.
</p>
<p>
The license was clarified in version 2.0.0
so that the code that SWIG generated could be distributed
under license terms of the user's choice/requirements and at the same time the SWIG
source was placed under the GNU General Public License version 3.
</p>
<H2><a name="Preface_nn5"></a>1.3 SWIG resources</H2>
<H2><a name="Preface_nn5"></a>1.4 SWIG resources</H2>
<p>
@ -93,16 +116,17 @@ SWIG along with information about beta releases and future work.
</p>
<p>
Subversion access to the latest version of SWIG is also available. More information
Git and Subversion access to the latest version of SWIG is also available. More information
about this can be obtained at:
</p>
<div class="shell"><pre>
<a href="http://www.swig.org/svn.html">http://www.swig.org/svn.html</a>
<a href="http://www.swig.org/svn.html">SWIG Bleeding Edge</a>
</pre></div>
<H2><a name="Preface_nn6"></a>1.4 Prerequisites</H2>
<H2><a name="Preface_nn6"></a>1.5 Prerequisites</H2>
<p>
@ -127,7 +151,7 @@ However, this isn't meant to be a tutorial on C++ programming. For many
of the gory details, you will almost certainly want to consult a good C++ reference. If you don't program
in C++, you may just want to skip those parts of the manual.
<H2><a name="Preface_nn7"></a>1.5 Organization of this manual</H2>
<H2><a name="Preface_nn7"></a>1.6 Organization of this manual</H2>
<p>
@ -139,7 +163,7 @@ can probably skip to that chapter and find almost everything you need
to know.
</p>
<H2><a name="Preface_nn8"></a>1.6 How to avoid reading the manual</H2>
<H2><a name="Preface_nn8"></a>1.7 How to avoid reading the manual</H2>
<p>
@ -151,7 +175,7 @@ The SWIG distribution also comes with a large directory of
examples that illustrate different topics.
</p>
<H2><a name="Preface_nn9"></a>1.7 Backwards compatibility</H2>
<H2><a name="Preface_nn9"></a>1.8 Backwards compatibility</H2>
<p>
@ -162,8 +186,8 @@ this isn't always possible as the
primary goal over time is to make SWIG
better---a process that would simply be impossible if the developers
are constantly bogged down with backwards compatibility issues.
Potential incompatibilities are clearly marked in the detailed release notes
(CHANGES files).
Potential incompatibilities are clearly marked in the detailed
<a href="#Preface_release_notes">release notes</a>.
</p>
@ -187,7 +211,16 @@ Note: The version symbol is not defined in the generated SWIG
wrapper file. The SWIG preprocessor has defined SWIG_VERSION since SWIG-1.3.11.
</p>
<H2><a name="Preface_nn10"></a>1.8 Credits</H2>
<H2><a name="Preface_release_notes"></a>1.9 Release notes</H2>
<p>
The CHANGES.current, CHANGES and RELEASENOTES files shipped with SWIG in the top level directory
contain, respectively, detailed release notes for the current version,
detailed release notes for previous releases and summary release notes from SWIG-1.3.22 onwards.
</p>
<H2><a name="Preface_nn10"></a>1.10 Credits</H2>
<p>
@ -200,7 +233,7 @@ who have made contributions at all levels over time. Contributors
are mentioned either in the COPYRIGHT file or CHANGES files shipped with SWIG or in submitted bugs.
</p>
<H2><a name="Preface_nn11"></a>1.9 Bug reports</H2>
<H2><a name="Preface_nn11"></a>1.11 Bug reports</H2>
<p>
@ -215,5 +248,204 @@ used, and any important pieces of the SWIG generated wrapper code. We
can only fix bugs if we know about them.
</p>
<H2><a name="Preface_installation"></a>1.12 Installation</H2>
<H3><a name="Preface_windows_installation"></a>1.12.1 Windows installation</H3>
<p>
Please see the dedicated <a href="Windows.html">Windows chapter</a> for instructions on installing
SWIG on Windows and running the examples. The Windows distribution is
called swigwin and includes a prebuilt SWIG executable, swig.exe, included in
the top level directory. Otherwise it is exactly the same as
the main SWIG distribution. There is no need to download anything else.
</p>
<H3><a name="Preface_unix_installation"></a>1.12.2 Unix installation</H3>
<p>
You must use <a href="http://www.gnu.org/software/make/">GNU make</a> to build and install SWIG.
</p>
<p>
<a href="http://www.pcre.org/">PCRE</a>
needs to be installed on your system to build SWIG, in particular
pcre-config must be available. If you have PCRE headers and libraries but not
pcre-config itself or, alternatively, wish to override the compiler or linker
flags returned by pcre-config, you may set PCRE_LIBS and PCRE_CFLAGS variables
to be used instead. And if you don't have PCRE at all, the configure script
will provide instructions for obtaining it.
</p>
<p>
To build and install SWIG, simply type the following:
</p>
<div class="shell"><pre>
$ ./configure
$ make
$ make install
</pre></div>
<p>
By default SWIG installs itself in /usr/local. If you need to install SWIG in
a different location or in your home directory, use the <tt>--prefix</tt> option
to <tt>./configure</tt>. For example:
</p>
<div class="shell"><pre>
$ ./configure --prefix=/home/yourname/projects
$ make
$ make install
</pre></div>
<p>
Note: the directory given to <tt>--prefix</tt> must be an absolute pathname. Do <b>not</b> use
the ~ shell-escape to refer to your home directory. SWIG won't work properly
if you do this.
</p>
<p>
The INSTALL file shipped in the top level directory details more about using configure. Also try
</p>
<div class="shell"><pre>
$ ./configure --help.
</pre></div>
<p>
The configure script will attempt to locate various packages on your machine
including Tcl, Perl5, Python and all the other target languages that SWIG
supports. Don't panic if you get 'not found' messages -- SWIG does not need these
packages to compile or run. The configure script is actually looking for
these packages so that you can try out the SWIG examples contained
in the 'Examples' directory without having to hack Makefiles.
Note that the <tt>--without-xxx</tt> options, where xxx is a target language, have
minimal effect. All they do is reduce the amount of testing done with
'make check'. The SWIG executable and library files installed cannot currently
be configured with a subset of target languages.
</p>
<p>
SWIG used to include a set of runtime libraries for some languages for working
with multiple modules. These are no longer built during the installation stage.
However, users can build them just like any wrapper module as described in
the <a href="Modules.html">Modules chapter</a>.
The CHANGES file shipped with SWIG in the top level directory
also lists some examples which build the runtime library.
</p>
<p>
Note:
</p>
<ul>
<li>
If you checked the code out via Git, you will have to run <tt>./autogen.sh</tt>
before <tt>./configure</tt>. In addition, a full build of SWIG requires
a number of packages to be installed. Full instructions at
<a href="http://www.swig.org/svn.html">SWIG bleeding edge</a>.
</li>
</ul>
<H3><a name="Preface_osx_installation"></a>1.12.3 Macintosh OS X installation</H3>
<p>
SWIG is known to work on various flavors of OS X. Follow the Unix installation
instructions above. However, as of this writing, there is still great deal of
inconsistency with how shared libaries are handled by various scripting languages
on OS X.
</p>
<p>
Users of OS X should be aware that Darwin handles shared libraries and linking in
a radically different way than most Unix systems. In order to test SWIG and run
the examples, SWIG configures itself to use flat namespaces and to allow undefined
symbols (<tt>-flat_namespace -undefined suppress</tt>). This mostly closely follows the Unix
model and makes it more likely that the SWIG examples will work with whatever
installation of software you might have. However, this is generally not the recommended
technique for building larger extension modules. Instead, you should utilize
Darwin's two-level namespaces. Some details about this can be found here
<a href="http://developer.apple.com/documentation/ReleaseNotes/DeveloperTools/TwoLevelNamespaces.html">http://developer.apple.com/documentation/ReleaseNotes/DeveloperTools/TwoLevelNamespaces.html</a>.
</p>
<p>
Needless to say, you might have to experiment a bit to get things working at first.
</p>
<H3><a name="Preface_testing"></a>1.12.4 Testing</H3>
<p>
If you want to test SWIG after building it, a check can be performed on Unix operating systems.
Type the following:
</p>
<div class="shell"><pre>
$ make -k check
</pre></div>
<p>
This step can be performed either before or after installation.
The check requires at least one of the target languages to be
installed. If it fails, it may mean that you have an uninstalled
language module or that the file 'Examples/Makefile' has been
incorrectly configured. It may also fail due to compiler issues such
as a broken C++ compiler. Even if the check fails, there is a
pretty good chance SWIG still works correctly --- you will just have to
mess around with one of the examples and some makefiles to get it to work.
Some tests may also fail due to missing dependency packages, eg PCRE
or Boost, but this will require careful analysis of the configure output
done during configuration.
</p>
<p>
The test suite executed by the check is designed to stress-test
many parts of the implementation including obscure corner cases. If some
of these tests fail or generate warning messages, there is no reason for
alarm --- the test may be related to some new SWIG feature or a difficult bug
that we're trying to resolve. Chances are that SWIG will work just fine
for you. Note that if you have more than one CPU/core, then you can use
parallel make to speed up the check as it does take quite some time to run,
for example:
</p>
<div class="shell"><pre>
$ make -j2 -k check
</pre></div>
<p>
Also, SWIG's support for C++ is sufficiently advanced that certain
tests may fail on older C++ compilers (for instance if your compiler
does not support member templates). These errors are harmless if you
don't intend to use these features in your own programs.
</p>
<p>
Note: The test-suite currently contains over 500 tests. If you
have many different target languages installed and a slow machine, it
might take more than an hour to run the test-suite.
</p>
<H3><a name="Preface_examples"></a>1.12.5 Examples</H3>
<p>
The Examples directory contains a variety of examples of using SWIG
and it has some browsable documentation. Simply point your browser to
the file "Example/index.html".
</p>
<p>
The Examples directory also includes Visual C++ project 6 (.dsp) files for
building some of the examples on Windows. Later versions of Visual Studio
will convert these old style project files into a current solution file.
</p>
</body>
</html>

37
Doc/Manual/Python.html
View file

@ -2345,7 +2345,7 @@ doesn't know how to add an instance of <tt>MyString</tt> to itself.
</li>
<li><p>If you have multiple SWIG modules that share type information (<a href="Modules.html#Modules_nn2">more info</a>),
the <tt>-builtin</tt> option requiress a bit of extra discipline to ensure that base classes are initialized before derived classes. Specifically:</p>
the <tt>-builtin</tt> option requires a bit of extra discipline to ensure that base classes are initialized before derived classes. Specifically:</p>
<ul>
<li><p>There must be an unambiguous dependency graph for the modules.</p></li>
<li><p>Module dependencies must be explicitly stated with <tt>%import</tt> statements in the SWIG interface file.</p>
@ -2782,9 +2782,6 @@ globally, to specific classes, and to specific methods, like this:
// generate directors for all virtual methods in class Foo
%feature("director") Foo;
// generate a director for just Foo::bar()
%feature("director") Foo::bar;
</pre>
</div>
@ -3389,7 +3386,39 @@ public:
</pre>
</div>
<p>
Note that when the underlying C++ method is overloaded, there is only one proxy Python method
for multiple C++ methods. In this case, only one of parsed methods is examined
for the feature. You are better off specifying the feature without the argument list to ensure it will get used,
as it will then get attached to all the overloaded C++ methods. For example:
</p>
<div class="code">
<pre>
%module example
// Add python code to bar()
%pythonprepend Foo::bar %{
#do something before C++ call
%}
%pythonappend Foo::bar %{
#do something after C++ call
%}
class Foo {
public:
int bar(int x);
int bar();
}
</pre>
</div>
<p>
The same applies for overloaded constructors.
</p>
<H3><a name="Python_nn43"></a>34.6.3 Class extension with %extend</H3>

4
Doc/Manual/README
View file

@ -1,9 +1,9 @@
This directory contains the HTML for the SWIG users manual.
All of this HTML is hand-written. However, section numbering, indices,
and the table of contents is generated automatically by the 'maketoc.py'
and the table of contents are generated automatically by the 'maketoc.py'
script. The Makefile has further information on how the various alternative
forms of the documentation is generated from the hand-written HTML.
forms of the documentation are generated from the hand-written HTML.
There are 4 types of boxes that code or whatever can be inside:
- <div class="shell">...</div>

13
Doc/Manual/Ruby.html
View file

@ -398,7 +398,8 @@ can add this: </p>
<p> to the end of the <tt>extconf.rb</tt> file. If
for some reason you don't want to use the standard approach, you'll
need to determine the correct compiler and linker flags for your build
platform. For example, a typical sequence of commands for the Linux
platform. For example, assuming you have code you need to link to in a file
called <tt>example.c</tt>, a typical sequence of commands for the Linux
operating system would look something like this: </p>
@ -3214,7 +3215,7 @@ directive which is unique to the Ruby module and was introduced in SWIG
<div class="code">
<pre>%bang sort!(arr);<br><br>int sort(int arr[]); </pre>
<pre>%bang sort(int arr[]);<br><br>int sort(int arr[]); </pre>
@ -4925,7 +4926,7 @@ arguments. For example: </p>
<div class="code">
<pre>%typemap(in) (char *str, int len) {<br> $1 = STR2CSTR($input);<br> $2 = (int) RSTRING($input)-&gt;len;<br>};<br><br>int count(char c, char *str, int len);<br></pre>
<pre>%typemap(in) (char *str, int len) {<br> $1 = StringValuePtr($input);<br> $2 = (int) RSTRING($input)-&gt;len;<br>};<br><br>int count(char c, char *str, int len);<br></pre>
@ -7134,7 +7135,7 @@ Ruby_Format_TypeError( "$1_name", "$1_type","$symname", $argnum, $input
</tr>
<tr>
<td style="font-family: monospace;">char * STR2CSTR(String)</td>
<td style="font-family: monospace;">char * StringValuePtr(String)</td>
<td style="font-family: monospace;">SWIG_AsCharPtrAndSize(VALUE, char*, size_t, int* alloc)</td>
</tr>
@ -7517,7 +7518,7 @@ Array instance to be used as a <tt>char **</tt> object. </p>
<div class="code">
<pre>%module argv<br><br>// This tells SWIG to treat char ** as a special case<br>%typemap(in) char ** {<br> /* Get the length of the array */<br> int size = RARRAY($input)-&gt;len; <br> int i;<br> $1 = (char **) malloc((size+1)*sizeof(char *));<br> /* Get the first element in memory */<br> VALUE *ptr = RARRAY($input)-&gt;ptr; <br> for (i=0; i &lt; size; i++, ptr++)<br> /* Convert Ruby Object String to char* */<br> $1[i]= STR2CSTR(*ptr); <br> $1[i]=NULL; /* End of list */<br>}<br><br>// This cleans up the char ** array created before <br>// the function call<br><br>%typemap(freearg) char ** {<br> free((char *) $1);<br>}<br><br>// Now a test function<br>%inline %{<br>int print_args(char **argv) {<br> int i = 0;<br> while (argv[i]) {<br> printf("argv[%d] = %s\n", i,argv[i]);<br> i++;<br> }<br> return i;<br>}<br>%}<br><br></pre>
<pre>%module argv<br><br>// This tells SWIG to treat char ** as a special case<br>%typemap(in) char ** {<br> /* Get the length of the array */<br> int size = RARRAY($input)-&gt;len; <br> int i;<br> $1 = (char **) malloc((size+1)*sizeof(char *));<br> /* Get the first element in memory */<br> VALUE *ptr = RARRAY($input)-&gt;ptr; <br> for (i=0; i &lt; size; i++, ptr++)<br> /* Convert Ruby Object String to char* */<br> $1[i]= StringValuePtr(*ptr); <br> $1[i]=NULL; /* End of list */<br>}<br><br>// This cleans up the char ** array created before <br>// the function call<br><br>%typemap(freearg) char ** {<br> free((char *) $1);<br>}<br><br>// Now a test function<br>%inline %{<br>int print_args(char **argv) {<br> int i = 0;<br> while (argv[i]) {<br> printf("argv[%d] = %s\n", i,argv[i]);<br> i++;<br> }<br> return i;<br>}<br>%}<br><br></pre>
@ -7795,7 +7796,7 @@ equivalents and store them in our local C arrays: </p>
<div class="code">
<pre>%typemap(in) (int nattributes, const char **names, const int *values)<br> (VALUE keys_arr, int i, VALUE key, VALUE val) {<br> Check_Type($input, T_HASH);<br> $1 = NUM2INT(rb_funcall($input, rb_intern("size"), 0, NULL));<br> $2 = NULL;<br> $3 = NULL;<br> if ($1 &gt; 0) {<br> $2 = (char **) malloc($1*sizeof(char *));<br> $3 = (int *) malloc($1*sizeof(int));<br> keys_arr = rb_funcall($input, rb_intern("keys"), 0, NULL);<br> for (i = 0; i &lt; $1; i++) {<br> key = rb_ary_entry(keys_arr, i);<br> val = rb_hash_aref($input, key);<br> Check_Type(key, T_STRING);<br> Check_Type(val, T_FIXNUM);<br> <b>$2[i] = STR2CSTR(key);<br> $3[i] = NUM2INT(val);</b><br>}<br>}<br>}<br></pre>
<pre>%typemap(in) (int nattributes, const char **names, const int *values)<br> (VALUE keys_arr, int i, VALUE key, VALUE val) {<br> Check_Type($input, T_HASH);<br> $1 = NUM2INT(rb_funcall($input, rb_intern("size"), 0, NULL));<br> $2 = NULL;<br> $3 = NULL;<br> if ($1 &gt; 0) {<br> $2 = (char **) malloc($1*sizeof(char *));<br> $3 = (int *) malloc($1*sizeof(int));<br> keys_arr = rb_funcall($input, rb_intern("keys"), 0, NULL);<br> for (i = 0; i &lt; $1; i++) {<br> key = rb_ary_entry(keys_arr, i);<br> val = rb_hash_aref($input, key);<br> Check_Type(key, T_STRING);<br> Check_Type(val, T_FIXNUM);<br> <b>$2[i] = StringValuePtr(key);<br> $3[i] = NUM2INT(val);</b><br>}<br>}<br>}<br></pre>

43
Doc/Manual/SWIG.html
View file

@ -2699,7 +2699,7 @@ the following declaration :</p>
<div class="code"><pre>
/* file : vector.h */
...
typedef struct {
typedef struct Vector {
double x,y,z;
} Vector;
@ -2772,7 +2772,7 @@ of the Vector structure. For example:</p>
#include "vector.h"
%}
typedef struct {
typedef struct Vector {
double x,y,z;
%extend {
Vector(double x, double y, double z) { ... }
@ -2783,7 +2783,7 @@ typedef struct {
</pre></div>
<p>
Finally, <tt>%extend</tt> can be used to access externally written
Note that <tt>%extend</tt> can be used to access externally written
functions provided they follow the naming convention used in this
example :</p>
@ -2814,7 +2814,7 @@ double Vector_magnitude(Vector *v) {
#include "vector.h"
%}
typedef struct {
typedef struct Vector {
double x,y,z;
%extend {
Vector(int,int,int); // This calls new_Vector()
@ -2826,6 +2826,37 @@ typedef struct {
</pre>
</div>
<p>
The name used for %extend should be the name of the struct and not the name of any typedef to the struct.
For example:
</p>
<div class="code"><pre>
typedef struct Integer {
int value;
} Int;
%extend Integer { ... } /* Correct name */
%extend Int { ... } /* Incorrect name */
struct Float {
float value;
};
typedef struct Float FloatValue;
%extend Float { ... } /* Correct name */
%extend FloatValue { ... } /* Incorrect name */
</pre></div>
<p>
There is one exception to this rule and that is when the struct is anonymously named such as:
</p>
<div class="code"><pre>
typedef struct {
double value;
} Double;
%extend Double { ... } /* Okay */
</pre></div>
<p>
A little known feature of the <tt>%extend</tt> directive is that
it can also be used to add synthesized attributes or to modify the
@ -2862,7 +2893,7 @@ For example, consider this interface:
<div class="code">
<pre>
typedef struct {
typedef struct Person {
char name[50];
...
} Person;
@ -2876,7 +2907,7 @@ the interface as follows to ensure this occurs whenever a name is read or writte
<div class="code">
<pre>
typedef struct {
typedef struct Person {
%extend {
char name[50];
}

12
Doc/Manual/SWIGPlus.html
View file

@ -2838,6 +2838,12 @@ struct Derived : Base {
}
</pre></div>
<p>
The following special variables are expanded if used within a %extend block:
$name, $symname, $overname, $decl, $fulldecl, $parentname and $parentsymname.
The <a href="Customization.html#Customization_exception_special_variables">Special variables</a> section provides more information each of these special variables.
</p>
<p>
The<tt> %extend</tt> directive follows all of the same conventions
as its use with C structures. Please refer to the <a href="SWIG.html#SWIG_adding_member_functions">Adding member functions to C structures</a>
@ -3121,8 +3127,8 @@ nothing is known about <tt>List&lt;int&gt;</tt>, you will get a warning message
<div class="shell">
<pre>
example.h:42. Nothing known about class 'List&lt;int &gt;' (ignored).
example.h:42. Maybe you forgot to instantiate 'List&lt;int &gt;' using %template.
example.h:42: Warning 401. Nothing known about class 'List&lt;int &gt;'. Ignored.
example.h:42: Warning 401. Maybe you forgot to instantiate 'List&lt;int &gt;' using %template.
</pre>
</div>
@ -3163,7 +3169,7 @@ Don't worry--if you get the order wrong, SWIG should generate a warning message.
Occasionally, you may need to tell SWIG about base classes that are defined by templates,
but which aren't supposed to be wrapped. Since SWIG is not able to automatically
instantiate templates for this purpose, you must do it manually. To do this, simply
use <tt>%template</tt> with no name. For example:
use the empty template instantiation, that is, <tt>%template</tt> with no name. For example:
</p>
<div class="code">

2
Doc/Manual/Sections.html
View file

@ -6,7 +6,7 @@
<body bgcolor="#ffffff">
<H1><a name="Sections"></a>SWIG-2.0 Documentation</H1>
Last update : SWIG-2.0.6 (30 April 2012)
Last update : SWIG-2.0.10 (in progress)
<H2>Sections</H2>

3
Doc/Manual/Tcl.html
View file

@ -132,7 +132,8 @@ header file.
<p>
The preferred approach to building an extension module is to compile it into
a shared object file or DLL. To do this, you will need to compile your program
a shared object file or DLL. Assuming you have code you need to link to in a file
called <tt>example.c</tt>, you will need to compile your program
using commands like this (shown for Linux):
</p>

2
Doc/Manual/Typemaps.html
View file

@ -773,7 +773,7 @@ Here are some examples of valid typemap specifications:
}
/* Typemap with modifiers */
%typemap(in,doc="integer") int "$1 = gh_scm2int($input);";
%typemap(in,doc="integer") int "$1 = scm_to_int($input);";
/* Typemap applied to patterns of multiple arguments */
%typemap(in) (char *str, int len),

70
Doc/Manual/Varargs.html
View file

@ -398,7 +398,7 @@ int execlp(const char *path, const char *arg, ...);
</div>
<p>
Note that <tt>str3</tt> is the name of the last argument, as we have used <tt>%vargars</tt> with 3.
Note that <tt>str3</tt> is the name of the last argument, as we have used <tt>%varargs</tt> with 3.
Now <tt>execlp("a", "b", "c", "d", "e")</tt> will result in an error as one too many arguments has been passed,
as now only 2 additional 'str' arguments can be passed with the 3rd one always using the specified default <tt>NULL</tt>.
</p>
@ -509,10 +509,10 @@ like this:
<div class="code">
<pre>
%typemap(in) (...)(char *args[10]) {
%typemap(in) (...)(char *vargs[10]) {
int i;
int argc;
for (i = 0; i &lt; 10; i++) args[i] = 0;
for (i = 0; i &lt; 10; i++) vargs[i] = 0;
argc = PyTuple_Size(varargs);
if (argc &gt; 10) {
PyErr_SetString(PyExc_ValueError, "Too many arguments");
@ -528,7 +528,7 @@ like this:
return NULL;
}
pystr = PyUnicode_AsUTF8String(pyobj);
str = PyBytes_AsString(pystr);
str = strdup(PyBytes_AsString(pystr));
Py_XDECREF(pystr);
%#else
if (!PyString_Check(pyobj)) {
@ -537,22 +537,34 @@ like this:
}
str = PyString_AsString(pyobj);
%#endif
args[i] = str;
vargs[i] = str;
}
$1 = (void *) args;
$1 = (void *)vargs;
}
%typemap(freearg) (...) {
%#if PY_VERSION_HEX&gt;=0x03000000
int i;
for (i = 0; i &lt; 10; i++) {
free(vargs$argnum[i]);
}
%#endif
}
</pre>
</div>
<p>
In this typemap, the special variable <tt>varargs</tt> is a tuple
In the 'in' typemap, the special variable <tt>varargs</tt> is a tuple
holding all of the extra arguments passed (this is specific to the
Python module). The typemap then pulls this apart and sticks the
values into the array of strings <tt>args</tt>. Then, the array is
assigned to <tt>$1</tt> (recall that this is the <tt>void *</tt>
variable corresponding to <tt>(...)</tt>). However, this assignment
is only half of the picture----clearly this alone is not enough to
make the function work. To patch everything up, you have to rewrite the
make the function work. The 'freearg' typemap cleans up memory
allocated in the 'in' typemap; this code is generated to be called
after the <tt>execlp</tt> function is called. To patch everything
up, you have to rewrite the
underlying action code using the <tt>%feature</tt> directive like
this:
</p>
@ -560,9 +572,9 @@ this:
<div class="code">
<pre>
%feature("action") execlp {
char *args = (char **) arg3;
result = execlp(arg1, arg2, args[0], args[1], args[2], args[3], args[4],
args[5],args[6],args[7],args[8],args[9], NULL);
char **vargs = (char **) arg3;
result = execlp(arg1, arg2, vargs[0], vargs[1], vargs[2], vargs[3], vargs[4],
vargs[5], vargs[6], vargs[7], vargs[8], vargs[9], NULL);
}
int execlp(const char *path, const char *arg, ...);
@ -839,13 +851,13 @@ of type <tt>va_list</tt>. For example:
<div class="code">
<pre>
int vfprintf(FILE *f, const char *fmt, va_list ap);
int vprintf(const char *fmt, va_list ap);
</pre>
</div>
<p>
As far as we know, there is no obvious way to wrap these functions
with SWIG. This is because there is no documented way to assemble the
As far as we know, there is no obvious way to wrap these functions with
SWIG. This is because there is no documented way to assemble the
proper va_list structure (there are no C library functions to do it
and the contents of va_list are opaque). Not only that, the contents
of a <tt>va_list</tt> structure are closely tied to the underlying
@ -853,6 +865,36 @@ call-stack. It's not clear that exporting a <tt>va_list</tt> would
have any use or that it would work at all.
</p>
<p>
A workaround can be implemented by writing a simple varargs C wrapper and then using the techniques
discussed earlier in this chapter for varargs. Below is a simple wrapper for <tt>vprintf</tt> renamed so that
it can still be called as <tt>vprintf</tt> from your target language. The <tt>%varargs</tt>
used in the example restricts the function to taking one string argument.
</p>
<div class="code">
<pre>
%{
int vprintf(const char *fmt, va_list ap);
%}
%varargs(const char *) my_vprintf;
%rename(vprintf) my_vprintf;
%inline %{
int my_vprintf(const char *fmt, ...) {
va_list ap;
int result;
va_start(ap, fmt);
result = vprintf(fmt, ap);
va_end(ap);
return result;
}
%}
</pre>
</div>
<H2><a name="Varargs_nn9"></a>13.8 C++ Issues</H2>

7
Doc/Manual/Warnings.html
View file

@ -423,7 +423,8 @@ example.i(4) : Syntax error in input.
<li>322. Redundant redeclaration of '<em>name</em>'.
<li>323. Recursive scope inheritance of '<em>name</em>'.
<li>324. Named nested template instantiations not supported. Processing as if no name was given to %template().
<li>325. Nested class not currently supported (<em>name</em> ignored).
<li>325. Nested <em>kind</em> not currently supported (<em>name</em> ignored).
<li>326. Deprecated %extend name used - the <em>kind</em> name '<em>name</em>' should be used instead of the typedef name '<em>name</em>'.
<li>350. operator new ignored.
<li>351. operator delete ignored.
<li>352. operator+ ignored.
@ -526,6 +527,8 @@ example.i(4) : Syntax error in input.
<li>519. %template() contains no name. Template method ignored: <em>declaration</em>
<li>520. <em>Base/Derived</em> class '<em>classname1</em>' of '<em>classname2</em>' is not similarly marked as a smart pointer.
<li>521. Illegal destructor name <em>name</em>. Ignored.
<li>522. Use of an illegal constructor name '<em>name</em>' in %extend is deprecated, the constructor name should be '<em>name</em>'.
<li>523. Use of an illegal destructor name '<em>name</em>' in %extend is deprecated, the destructor name should be '<em>name</em>'.
</ul>
<H3><a name="Warnings_nn15"></a>14.9.6 Language module specific (700-899) </H3>
@ -551,6 +554,8 @@ example.i(4) : Syntax error in input.
<li>822. Covariant return types not supported in Java. Proxy method will return <em>basetype</em> (Java).
<li>823. No javaconstruct typemap defined for <em>type</em> (Java).
<li>824. Missing JNI descriptor in directorin typemap defined for <em>type</em> (Java).
<li>825. "directorconnect" attribute missing in <em>type</em> "javaconstruct" typemap. (Java).
<li>826. The nspace feature is used on '<em>type</em>' without -package. The generated code may not compile as Java does not support types declared in a named package accessing types declared in an unnamed package. (Java).
</ul>
<ul>

14
Doc/Manual/Windows.html
View file

@ -236,8 +236,8 @@ The short abbreviated instructions follow...
</ul>
<p>
The step by step instructions to download and install MinGW and MSYS, then download and build the latest version of SWIG from SVN follow...
Note that the instructions for obtaining SWIG from SVN are also online at <a href="http://www.swig.org/svn.html">SWIG SVN</a>.
The step by step instructions to download and install MinGW and MSYS, then download and build the latest version of SWIG from Github follow...
Note that the instructions for obtaining SWIG from Github are also online at <a href="http://www.swig.org/svn.html">SWIG Bleeding Edge</a>.
</p>
<p>
@ -300,15 +300,19 @@ tar -zxf bison-2.0-MSYS.tar.gz
</li>
<li>
To get the latest SWIG SVN (version from Subversion source control), type in the following:
The very latest development version of SWIG is available from <a href="https://github.com/swig/swig">SWIG on Github</a>
and can be downloaded as a zip file or if you have Git installed, via Git.
Either download the latest <a href="https://github.com/swig/swig/archive/master.zip">Zip file</a> snapshot and unzip and rename the top level folder to /usr/src/swig.
Otherwise if using Git, type in the following:
<div class="shell"><pre>
mkdir /usr/src
cd /usr/src
svn co https://swig.svn.sourceforge.net/svnroot/swig/trunk swig
git clone https://github.com/swig/swig.git
</pre></div>
<b>Pitfall note:</b>
If you want to check out SWIG to a different folder to the proposed
If you want to place SWIG in a different folder to the proposed
/usr/src/swig, do not use MSYS emulated windows drive letters, because
the autotools will fail miserably on those.
</li>

100
Doc/Manual/margin-left.patch
View file

@ -1,25 +1,66 @@
#
# Patch managed by http://www.holgerschurig.de/patcher.html
#
# This patch is against htmldoc 1.8.24, and it hacks in support for
# This patch is against htmldoc 1.8.27, and it hacks in support for
# correctly indenting the <div class=""> sections in the SWIG manual.
# This patch should only be used until the 1.9 branch of htmldoc
# stabalizes, since the 1.9 branch includes true CSS1 support.
# stabilizes, since the 1.9 branch includes true CSS1 support.
#
# This patch only affects the PDF generation, an unpatched htmldoc
# creates the one-page html documentation just fine.
#
--- htmldoc-1.8.24/htmldoc/ps-pdf.cxx~margin-left
+++ htmldoc-1.8.24/htmldoc/ps-pdf.cxx
@@ -158,6 +158,7 @@
diff -Naur htmldoc-1.8.27/htmldoc/htmldoc.cxx htmldoc-1.8.27-margin-left/htmldoc/htmldoc.cxx
--- htmldoc-1.8.27/htmldoc/htmldoc.cxx 2006-03-30 14:01:20.000000000 +0100
+++ htmldoc-1.8.27-margin-left/htmldoc/htmldoc.cxx 2013-05-11 10:11:47.428435647 +0100
@@ -65,6 +65,8 @@
const char *__XOS2RedirRoot(const char *);
}
#endif
+
+extern void parse_style(char *);
/*
@@ -1115,6 +1117,7 @@
else if (compare_strings(argv[i], "--version", 6) == 0)
{
puts(SVERSION);
+ puts("Patched with margin-left.patch");
return (0);
}
else if (compare_strings(argv[i], "--webpage", 3) == 0)
@@ -2403,6 +2406,10 @@
}
else if (strcmp(temp, "--cookies") == 0)
file_cookies(temp2);
+ else if (strcmp(temp, "--stylesheet") == 0)
+ {
+ parse_style(temp2);
+ }
}
}
diff -Naur htmldoc-1.8.27/htmldoc/Makefile htmldoc-1.8.27-margin-left/htmldoc/Makefile
--- htmldoc-1.8.27/htmldoc/Makefile 2005-10-28 21:32:59.000000000 +0100
+++ htmldoc-1.8.27-margin-left/htmldoc/Makefile 2013-05-11 09:39:04.392367869 +0100
@@ -36,7 +36,7 @@
OBJS = gui.o file.o html.o htmldoc.o htmllib.o htmlsep.o \
http.o http-addr.o http-addrlist.o http-support.o image.o \
iso8859.o license.o md5.o progress.o ps-pdf.o rc4.o \
- snprintf.o string.o toc.o util.o
+ snprintf.o string.o toc.o util.o style.o
#
diff -Naur htmldoc-1.8.27/htmldoc/ps-pdf.cxx htmldoc-1.8.27-margin-left/htmldoc/ps-pdf.cxx
--- htmldoc-1.8.27/htmldoc/ps-pdf.cxx 2006-08-01 17:58:50.000000000 +0100
+++ htmldoc-1.8.27-margin-left/htmldoc/ps-pdf.cxx 2013-05-11 09:37:40.096364957 +0100
@@ -160,6 +160,7 @@
# undef page_t
#endif // __hpux
+extern int lookup_div_class(uchar *);
/*
* Constants...
@@ -4188,9 +4189,24 @@
* Output options...
@@ -4230,9 +4231,24 @@
para->child = para->last_child = NULL;
}
@ -45,30 +86,9 @@
if (para->child != NULL)
{
parse_paragraph(para, *left, *right, *bottom, *top, x, y, page, *needspace);
--- htmldoc-1.8.24/htmldoc/htmldoc.cxx~margin-left
+++ htmldoc-1.8.24/htmldoc/htmldoc.cxx
@@ -62,6 +62,8 @@
const char *__XOS2RedirRoot(const char *);
}
#endif
+
+extern void parse_style(char *);
/*
@@ -2140,6 +2142,10 @@
}
else if (strcmp(temp, "--cookies") == 0)
file_cookies(temp2);
+ else if (strcmp(temp, "--stylesheet") == 0)
+ {
+ parse_style(temp2);
+ }
}
}
--- /dev/null
+++ htmldoc-1.8.24/htmldoc/style.cxx
diff -Naur htmldoc-1.8.27/htmldoc/style.cxx htmldoc-1.8.27-margin-left/htmldoc/style.cxx
--- htmldoc-1.8.27/htmldoc/style.cxx 1970-01-01 01:00:00.000000000 +0100
+++ htmldoc-1.8.27-margin-left/htmldoc/style.cxx 2013-05-11 09:37:40.096364957 +0100
@@ -0,0 +1,185 @@
+/* Extreamly simple parsing routines for CSS style sheets.
+ * We only parse div.class { } sections, and only look
@ -255,15 +275,3 @@
+
+ fclose(f);
+}
--- htmldoc-1.8.24/htmldoc/Makefile~margin-left
+++ htmldoc-1.8.24/htmldoc/Makefile
@@ -35,7 +35,7 @@
OBJS = gui.o file.o html.o htmldoc.o htmllib.o htmlsep.o http.o \
http-addr.o http-support.o image.o iso8859.o license.o md5.o \
- progress.o ps-pdf.o rc4.o snprintf.o string.o toc.o util.o
+ progress.o ps-pdf.o rc4.o snprintf.o string.o toc.o util.o style.o
#

592
Examples/Makefile.in
View file

File diff suppressed because it is too large Load diff

1
Examples/android/check.list
View file

@ -1,3 +1,4 @@
# see top-level Makefile.in
class
extend
simple

29
Examples/android/class/Makefile
View file

@ -2,28 +2,25 @@ TOP = ../..
SWIG = $(TOP)/../preinst-swig
TARGET = example
INTERFACE = example.i
INTERFACEDIR = jni/
PACKAGEDIR = src/org/swig
PACKAGENAME= org.swig.classexample
SWIGOPT = -package $(PACKAGENAME) -outdir $(PACKAGEDIR)/classexample
PROJECTNAME= SwigClass
TARGETID = 1
#INSTALLOPTIONS = -s # To install on SD Card
all:: android
check: build
android::
android update project --target $(TARGETID) --name $(PROJECTNAME) --path .
$(SWIG) -c++ -java $(SWIGOPT) -o jni/$(TARGET)_wrap.cpp jni/$(INTERFACE)
ndk-build
ant debug
build:
$(MAKE) -f $(TOP)/Makefile CXXSRCS='$(CXXSRCS)' SWIG='$(SWIG)' SWIGOPT='$(SWIGOPT)' \
TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' INTERFACEDIR='$(INTERFACEDIR)' \
PROJECTNAME='$(PROJECTNAME)' TARGETID='$(TARGETID)' android_cpp
install::
-adb uninstall $(PACKAGENAME)
adb install bin/$(PROJECTNAME)-debug.apk
install:
$(MAKE) -f $(TOP)/Makefile INSTALLOPTIONS='$(INSTALLOPTIONS)' PROJECTNAME='$(PROJECTNAME)' \
PACKAGEDIR='$(PACKAGEDIR)' PACKAGENAME='$(PACKAGENAME)' android_install
clean::
ant clean
rm -f jni/$(TARGET)_wrap.cpp
rm -f `find $(PACKAGEDIR) -name \*.java | grep -v $(PROJECTNAME).java`
check: all
clean:
$(MAKE) -f $(TOP)/Makefile TARGET='$(TARGET)' PROJECTNAME='$(PROJECTNAME)' \
PACKAGEDIR='$(PACKAGEDIR)' INTERFACEDIR='$(INTERFACEDIR)' android_clean

15
Examples/android/extend/AndroidManifest.xml Normal file
View file

@ -0,0 +1,15 @@
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="org.swig.extendexample"
android:versionCode="1"
android:versionName="1.0">
<application android:label="@string/app_name" >
<activity android:name="SwigExtend"
android:label="@string/app_name">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
</application>
</manifest>

26
Examples/android/extend/Makefile Normal file
View file

@ -0,0 +1,26 @@
TOP = ../..
SWIG = $(TOP)/../preinst-swig
TARGET = example
INTERFACE = example.i
INTERFACEDIR = jni/
PACKAGEDIR = src/org/swig
PACKAGENAME= org.swig.extendexample
SWIGOPT = -package $(PACKAGENAME) -outdir $(PACKAGEDIR)/extendexample
PROJECTNAME= SwigExtend
TARGETID = 1
#INSTALLOPTIONS = -s # To install on SD Card
check: build
build:
$(MAKE) -f $(TOP)/Makefile CXXSRCS='$(CXXSRCS)' SWIG='$(SWIG)' SWIGOPT='$(SWIGOPT)' \
TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' INTERFACEDIR='$(INTERFACEDIR)' \
PROJECTNAME='$(PROJECTNAME)' TARGETID='$(TARGETID)' android_cpp
install:
$(MAKE) -f $(TOP)/Makefile INSTALLOPTIONS='$(INSTALLOPTIONS)' PROJECTNAME='$(PROJECTNAME)' \
PACKAGEDIR='$(PACKAGEDIR)' PACKAGENAME='$(PACKAGENAME)' android_install
clean:
$(MAKE) -f $(TOP)/Makefile TARGET='$(TARGET)' PROJECTNAME='$(PROJECTNAME)' \
PACKAGEDIR='$(PACKAGEDIR)' INTERFACEDIR='$(INTERFACEDIR)' android_clean

17
Examples/android/extend/ant.properties Normal file
View file

@ -0,0 +1,17 @@
# This file is used to override default values used by the Ant build system.
#
# This file must be checked in Version Control Systems, as it is
# integral to the build system of your project.
# This file is only used by the Ant script.
# You can use this to override default values such as
# 'source.dir' for the location of your java source folder and
# 'out.dir' for the location of your output folder.
# You can also use it define how the release builds are signed by declaring
# the following properties:
# 'key.store' for the location of your keystore and
# 'key.alias' for the name of the key to use.
# The password will be asked during the build when you use the 'release' target.

85
Examples/android/extend/build.xml Normal file
View file

@ -0,0 +1,85 @@
<?xml version="1.0" encoding="UTF-8"?>
<project name="SwigExtend" default="help">
<!-- The local.properties file is created and updated by the 'android' tool.
It contains the path to the SDK. It should *NOT* be checked into
Version Control Systems. -->
<loadproperties srcFile="local.properties" />
<!-- The ant.properties file can be created by you. It is only edited by the
'android' tool to add properties to it.
This is the place to change some Ant specific build properties.
Here are some properties you may want to change/update:
source.dir
The name of the source directory. Default is 'src'.
out.dir
The name of the output directory. Default is 'bin'.
For other overridable properties, look at the beginning of the rules
files in the SDK, at tools/ant/build.xml
Properties related to the SDK location or the project target should
be updated using the 'android' tool with the 'update' action.
This file is an integral part of the build system for your
application and should be checked into Version Control Systems.
-->
<property file="ant.properties" />
<!-- The project.properties file is created and updated by the 'android'
tool, as well as ADT.
This contains project specific properties such as project target, and library
dependencies. Lower level build properties are stored in ant.properties
(or in .classpath for Eclipse projects).
This file is an integral part of the build system for your
application and should be checked into Version Control Systems. -->
<loadproperties srcFile="project.properties" />
<!-- quick check on sdk.dir -->
<fail
message="sdk.dir is missing. Make sure to generate local.properties using 'android update project'"
unless="sdk.dir"
/>
<!-- extension targets. Uncomment the ones where you want to do custom work
in between standard targets -->
<!--
<target name="-pre-build">
</target>
<target name="-pre-compile">
</target>
/* This is typically used for code obfuscation.
Compiled code location: ${out.classes.absolute.dir}
If this is not done in place, override ${out.dex.input.absolute.dir} */
<target name="-post-compile">
</target>
-->
<!-- Import the actual build file.
To customize existing targets, there are two options:
- Customize only one target:
- copy/paste the target into this file, *before* the
<import> task.
- customize it to your needs.
- Customize the whole content of build.xml
- copy/paste the content of the rules files (minus the top node)
into this file, replacing the <import> task.
- customize to your needs.
***********************
****** IMPORTANT ******
***********************
In all cases you must update the value of version-tag below to read 'custom' instead of an integer,
in order to avoid having your file be overridden by tools such as "android update project"
-->
<!-- version-tag: 1 -->
<import file="${sdk.dir}/tools/ant/build.xml" />
</project>

10
Examples/android/extend/jni/Android.mk Normal file
View file

@ -0,0 +1,10 @@
# File: Android.mk
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := example
LOCAL_SRC_FILES := example_wrap.cpp example.cpp
LOCAL_CFLAGS := -frtti
include $(BUILD_SHARED_LIBRARY)

2
Examples/android/extend/jni/Application.mk Normal file
View file

@ -0,0 +1,2 @@
# File: Application.mk
APP_STL := gnustl_static

14
Examples/android/extend/jni/example.cpp Normal file
View file

@ -0,0 +1,14 @@
/* File : example.cxx */
#include "example.h"
static Streamer * streamerInstance = 0;
void setStreamer(Streamer* streamer) {
streamerInstance = streamer;
}
Streamer& getStreamer() {
return *streamerInstance;
}

71
Examples/android/extend/jni/example.h Normal file
View file

@ -0,0 +1,71 @@
/* File : example.h */
#include <cstdio>
#include <iostream>
#include <vector>
#include <string>
#include <cmath>
#include <sstream>
struct Streamer {
virtual void display(std::string text) const = 0;
virtual ~Streamer() {}
};
void setStreamer(Streamer* streamer);
Streamer& getStreamer();
template<typename T> Streamer& operator<<(Streamer& stream, T const& val) {
std::ostringstream s;
s << val;
stream.display(s.str());
return stream;
}
class Employee {
private:
std::string name;
public:
Employee(const char* n): name(n) {}
virtual std::string getTitle() { return getPosition() + " " + getName(); }
virtual std::string getName() { return name; }
virtual std::string getPosition() const { return "Employee"; }
virtual ~Employee() { getStreamer() << "~Employee() @ " << this << "\n"; }
};
class Manager: public Employee {
public:
Manager(const char* n): Employee(n) {}
virtual std::string getPosition() const { return "Manager"; }
};
class EmployeeList {
std::vector<Employee*> list;
public:
EmployeeList() {
list.push_back(new Employee("Bob"));
list.push_back(new Employee("Jane"));
list.push_back(new Manager("Ted"));
}
void addEmployee(Employee *p) {
list.push_back(p);
getStreamer() << "New employee added. Current employees are:" << "\n";
std::vector<Employee*>::iterator i;
for (i=list.begin(); i!=list.end(); i++) {
getStreamer() << " " << (*i)->getTitle() << "\n";
}
}
const Employee *get_item(int i) {
return list[i];
}
~EmployeeList() {
std::vector<Employee*>::iterator i;
getStreamer() << "~EmployeeList, deleting " << list.size() << " employees." << "\n";
for (i=list.begin(); i!=list.end(); i++) {
delete *i;
}
getStreamer() << "~EmployeeList empty." << "\n";
}
};

18
Examples/android/extend/jni/example.i Normal file
View file

@ -0,0 +1,18 @@
/* File : example.i */
%module(directors="1") example
%{
#include "example.h"
%}
%include "std_vector.i"
%include "std_string.i"
/* turn on director wrapping for Manager */
%feature("director") Employee;
%feature("director") Manager;
/* A base class for callbacks from C++ to output text on the Java side */
%feature("director") Streamer;
%include "example.h"

10
Examples/android/extend/local.properties Normal file
View file

@ -0,0 +1,10 @@
# This file is automatically generated by Android Tools.
# Do not modify this file -- YOUR CHANGES WILL BE ERASED!
#
# This file must *NOT* be checked in Version Control Systems,
# as it contains information specific to your local configuration.
# location of the SDK. This is only used by Ant
# For customization when using a Version Control System, please read the
# header note.
sdk.dir=/home/william/android/android-sdk-linux_x86

40
Examples/android/extend/proguard.cfg Normal file
View file

@ -0,0 +1,40 @@
-optimizationpasses 5
-dontusemixedcaseclassnames
-dontskipnonpubliclibraryclasses
-dontpreverify
-verbose
-optimizations !code/simplification/arithmetic,!field/*,!class/merging/*
-keep public class * extends android.app.Activity
-keep public class * extends android.app.Application
-keep public class * extends android.app.Service
-keep public class * extends android.content.BroadcastReceiver
-keep public class * extends android.content.ContentProvider
-keep public class * extends android.app.backup.BackupAgentHelper
-keep public class * extends android.preference.Preference
-keep public class com.android.vending.licensing.ILicensingService
-keepclasseswithmembernames class * {
native <methods>;
}
-keepclasseswithmembers class * {
public <init>(android.content.Context, android.util.AttributeSet);
}
-keepclasseswithmembers class * {
public <init>(android.content.Context, android.util.AttributeSet, int);
}
-keepclassmembers class * extends android.app.Activity {
public void *(android.view.View);
}
-keepclassmembers enum * {
public static **[] values();
public static ** valueOf(java.lang.String);
}
-keep class * implements android.os.Parcelable {
public static final android.os.Parcelable$Creator *;
}

11
Examples/android/extend/project.properties Normal file
View file

@ -0,0 +1,11 @@
# This file is automatically generated by Android Tools.
# Do not modify this file -- YOUR CHANGES WILL BE ERASED!
#
# This file must be checked in Version Control Systems.
#
# To customize properties used by the Ant build system use,
# "ant.properties", and override values to adapt the script to your
# project structure.
# Project target.
target=android-8

25
Examples/android/extend/res/layout/main.xml Normal file
View file

@ -0,0 +1,25 @@
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:orientation="vertical"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
>
<Button
android:id="@+id/RunButton"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="Run..."
android:onClick="onRunButtonClick"
/>
<ScrollView
android:id="@+id/Scroller"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
>
<TextView
android:id="@+id/OutputText"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
/>
</ScrollView>
</LinearLayout>

4
Examples/android/extend/res/values/strings.xml Normal file
View file

@ -0,0 +1,4 @@
<?xml version="1.0" encoding="utf-8"?>
<resources>
<string name="app_name">SwigExtend</string>
</resources>

129
Examples/android/extend/src/org/swig/extendexample/SwigExtend.java Normal file
View file

@ -0,0 +1,129 @@
package org.swig.extendexample;
import android.app.Activity;
import android.os.Bundle;
import android.view.View;
import android.widget.Button;
import android.widget.TextView;
import android.widget.ScrollView;
import android.text.method.ScrollingMovementMethod;
// CEO class, which overrides Employee::getPosition().
class CEO extends Manager {
public CEO(String name) {
super(name);
}
public String getPosition() {
return "CEO";
}
// Public method to stop the SWIG proxy base class from thinking it owns the underlying C++ memory.
public void disownMemory() {
swigCMemOwn = false;
}
}
public class SwigExtend extends Activity
{
TextView outputText = null;
ScrollView scroller = null;
/** Handles upcalls from C++ so that C++ code can display text on the TextView */
class TextViewStreamer extends Streamer {
public void display(String text) {
outputText.append(text);
}
}
TextViewStreamer textViewStreamer = new TextViewStreamer();
/** Called when the activity is first created. */
@Override
public void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
outputText = (TextView)findViewById(R.id.OutputText);
outputText.setText("Press 'Run' to start...\n");
outputText.setMovementMethod(new ScrollingMovementMethod());
scroller = (ScrollView)findViewById(R.id.Scroller);
example.setStreamer(textViewStreamer);
}
public void onRunButtonClick(View view)
{
outputText.append("Started...\n");
nativeCall();
outputText.append("Finished!\n");
// Ensure scroll to end of text
scroller.post(new Runnable() {
public void run() {
scroller.fullScroll(ScrollView.FOCUS_DOWN);
}
});
}
/** Calls into C/C++ code */
public void nativeCall()
{
// Create an instance of CEO, a class derived from the Java proxy of the
// underlying C++ class. The calls to getName() and getPosition() are standard,
// the call to getTitle() uses the director wrappers to call CEO.getPosition().
CEO e = new CEO("Alice");
outputText.append( e.getName() + " is a " + e.getPosition() + "\n");
outputText.append( "Just call her \"" + e.getTitle() + "\"\n" );
outputText.append( "----------------------\n" );
// Create a new EmployeeList instance. This class does not have a C++
// director wrapper, but can be used freely with other classes that do.
EmployeeList list = new EmployeeList();
// EmployeeList owns its items, so we must surrender ownership of objects we add.
e.disownMemory();
list.addEmployee(e);
outputText.append( "----------------------\n" );
// Now we access the first four items in list (three are C++ objects that
// EmployeeList's constructor adds, the last is our CEO). The virtual
// methods of all these instances are treated the same. For items 0, 1, and
// 2, all methods resolve in C++. For item 3, our CEO, getTitle calls
// getPosition which resolves in Java. The call to getPosition is
// slightly different, however, because of the overidden getPosition() call, since
// now the object reference has been "laundered" by passing through
// EmployeeList as an Employee*. Previously, Java resolved the call
// immediately in CEO, but now Java thinks the object is an instance of
// class Employee. So the call passes through the
// Employee proxy class and on to the C wrappers and C++ director,
// eventually ending up back at the Java CEO implementation of getPosition().
// The call to getTitle() for item 3 runs the C++ Employee::getTitle()
// method, which in turn calls getPosition(). This virtual method call
// passes down through the C++ director class to the Java implementation
// in CEO. All this routing takes place transparently.
outputText.append( "(position, title) for items 0-3:\n" );
outputText.append( " " + list.get_item(0).getPosition() + ", \"" + list.get_item(0).getTitle() + "\"\n" );
outputText.append( " " + list.get_item(1).getPosition() + ", \"" + list.get_item(1).getTitle() + "\"\n" );
outputText.append( " " + list.get_item(2).getPosition() + ", \"" + list.get_item(2).getTitle() + "\"\n" );
outputText.append( " " + list.get_item(3).getPosition() + ", \"" + list.get_item(3).getTitle() + "\"\n" );
outputText.append( "----------------------\n" );
// Time to delete the EmployeeList, which will delete all the Employee*
// items it contains. The last item is our CEO, which gets destroyed as well.
list.delete();
outputText.append( "----------------------\n" );
}
/** static constructor */
static {
System.loadLibrary("example");
}
}

29
Examples/android/simple/Makefile
View file

@ -2,28 +2,25 @@ TOP = ../..
SWIG = $(TOP)/../preinst-swig
TARGET = example
INTERFACE = example.i
INTERFACEDIR = jni/
PACKAGEDIR = src/org/swig
PACKAGENAME= org.swig.simple
SWIGOPT = -package $(PACKAGENAME) -outdir $(PACKAGEDIR)/simple
PROJECTNAME= SwigSimple
TARGETID = 1
#INSTALLOPTIONS = -s # To install on SD Card
all:: android
check: build
android::
android update project --target $(TARGETID) --name $(PROJECTNAME) --path .
$(SWIG) -java $(SWIGOPT) -o jni/$(TARGET)_wrap.c jni/$(INTERFACE)
ndk-build
ant debug
build:
$(MAKE) -f $(TOP)/Makefile CXXSRCS='$(CXXSRCS)' SWIG='$(SWIG)' SWIGOPT='$(SWIGOPT)' \
TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' INTERFACEDIR='$(INTERFACEDIR)' \
PROJECTNAME='$(PROJECTNAME)' TARGETID='$(TARGETID)' android
install::
-adb uninstall $(PACKAGENAME)
adb install bin/$(PROJECTNAME)-debug.apk
install:
$(MAKE) -f $(TOP)/Makefile INSTALLOPTIONS='$(INSTALLOPTIONS)' PROJECTNAME='$(PROJECTNAME)' \
PACKAGEDIR='$(PACKAGEDIR)' PACKAGENAME='$(PACKAGENAME)' android_install
clean::
ant clean
rm -f jni/$(TARGET)_wrap.c
rm -f `find $(PACKAGEDIR) -name \*.java | grep -v $(PROJECTNAME).java`
check: all
clean:
$(MAKE) -f $(TOP)/Makefile TARGET='$(TARGET)' PROJECTNAME='$(PROJECTNAME)' \
PACKAGEDIR='$(PACKAGEDIR)' INTERFACEDIR='$(INTERFACEDIR)' android_clean

28
Examples/chicken/class/Makefile
View file

@ -10,29 +10,29 @@ CFLAGS =
VARIANT =
# uncomment the following lines to build a static exe (only pick one of the CHICKEN_MAIN lines)
#CHICKEN_MAIN = test-lowlevel-class.scm
#CHICKEN_MAIN = test-tinyclos-class.scm
#CHICKEN_MAIN = runme-lowlevel.scm
#CHICKEN_MAIN = runme-tinyclos.scm
#VARIANT = _static
all:: $(TARGET) $(TARGET)_proxy
check: build
$(MAKE) -f $(TOP)/Makefile CHICKEN_SCRIPT='runme-lowlevel.scm' chicken_run
$(MAKE) -f $(TOP)/Makefile CHICKEN_SCRIPT='runme-tinyclos.scm' chicken_run
build: $(TARGET) $(TARGET)_proxy
$(TARGET): $(INTERFACE) $(SRCS)
$(MAKE) -f $(TOP)/Makefile \
SRCS='$(SRCS)' CXXSRCS='$(CXXSRCS)' CHICKEN_MAIN='$(CHICKEN_MAIN)' \
INCLUDE='$(INCLUDE)' SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' \
SWIG='$(SWIG)' INTERFACE='$(INTERFACE)' CHICKENOPTS='$(CHICKENOPTS)' chicken$(VARIANT)_cpp
SRCS='$(SRCS)' CXXSRCS='$(CXXSRCS)' CHICKEN_MAIN='$(CHICKEN_MAIN)' \
INCLUDE='$(INCLUDE)' SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' \
SWIG='$(SWIG)' INTERFACE='$(INTERFACE)' CHICKENOPTS='$(CHICKENOPTS)' chicken$(VARIANT)_cpp
$(TARGET)_proxy: $(INTERFACE) $(SRCS)
$(MAKE) -f $(TOP)/Makefile \
SRCS='$(SRCS)' CXXSRCS='$(CXXSRCS)' CHICKEN_MAIN='$(CHICKEN_MAIN)' \
INCLUDE='$(INCLUDE)' SWIGOPT='$(SWIGOPT) -proxy' TARGET='$(TARGET)_proxy' \
SWIG='$(SWIG)' INTERFACE='$(INTERFACE)' CHICKENOPTS='$(CHICKENOPTS)' chicken$(VARIANT)_cpp
SRCS='$(SRCS)' CXXSRCS='$(CXXSRCS)' CHICKEN_MAIN='$(CHICKEN_MAIN)' \
INCLUDE='$(INCLUDE)' SWIGOPT='$(SWIGOPT) -proxy' TARGET='$(TARGET)_proxy' \
SWIG='$(SWIG)' INTERFACE='$(INTERFACE)' CHICKENOPTS='$(CHICKENOPTS)' chicken$(VARIANT)_cpp
clean::
clean:
$(MAKE) -f $(TOP)/Makefile chicken_clean
rm -f example.scm
rm -f $(TARGET)
check::
env LD_LIBRARY_PATH=.:$$LD_LIBRARY_PATH csi test-lowlevel-class.scm
env LD_LIBRARY_PATH=.:$$LD_LIBRARY_PATH csi test-tinyclos-class.scm

0
Examples/chicken/class/test-lowlevel-class.scm → Examples/chicken/class/runme-lowlevel.scm
View file

0
Examples/chicken/class/test-tinyclos-class.scm → Examples/chicken/class/runme-tinyclos.scm
View file

18
Examples/chicken/constants/Makefile
View file

@ -10,21 +10,21 @@ CFLAGS =
VARIANT =
# uncomment the following two lines to build a static exe
#CHICKEN_MAIN = test-constants.scm
#CHICKEN_MAIN = runme.scm
#VARIANT = _static
all:: $(TARGET)
check: build
$(MAKE) -f $(TOP)/Makefile chicken_run
build: $(TARGET)
$(TARGET): $(INTERFACE) $(SRCS)
$(MAKE) -f $(TOP)/Makefile \
SRCS='$(SRCS)' CXXSRCS='$(CXXSRCS)' CHICKEN_MAIN='$(CHICKEN_MAIN)' \
INCLUDE='$(INCLUDE)' SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' \
SWIG='$(SWIG)' INTERFACE='$(INTERFACE)' CHICKENOPTS='$(CHICKENOPTS)' chicken$(VARIANT)
SRCS='$(SRCS)' CXXSRCS='$(CXXSRCS)' CHICKEN_MAIN='$(CHICKEN_MAIN)' \
INCLUDE='$(INCLUDE)' SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' \
SWIG='$(SWIG)' INTERFACE='$(INTERFACE)' CHICKENOPTS='$(CHICKENOPTS)' chicken$(VARIANT)
clean::
clean:
$(MAKE) -f $(TOP)/Makefile chicken_clean
rm -f example.scm
rm -f $(TARGET)
check::
csi test-constants.scm

0
Examples/chicken/constants/test-constants.scm → Examples/chicken/constants/runme.scm
View file

10
Examples/chicken/egg/Makefile
View file

@ -1,6 +1,9 @@
SWIG = ../../../preinst-swig
all: single multi
check: build
cd eggs/install && csi ../../test.scm
build: single multi
# This creates an egg which contains only the single module. Any additional implementation files
# that implement the interface being wrapped should also be added to this egg
@ -9,7 +12,7 @@ single: single_wrap.cxx
tar czf eggs/single.egg single.setup single.scm single_wrap.cxx
rm -f single.scm single_wrap.cxx
# complie the single module with -nounit
# compile the single module with -nounit
single_wrap.cxx: single.i
$(SWIG) -chicken -c++ -proxy -nounit single.i
@ -34,6 +37,3 @@ setup:
mkdir -p install && \
chicken-setup -repository `pwd`/install single.egg && \
chicken-setup -repository `pwd`/install multi.egg
check:
cd eggs/install && csi ../../test.scm

18
Examples/chicken/multimap/Makefile
View file

@ -10,21 +10,21 @@ CFLAGS =
VARIANT =
# uncomment the following two lines to build a static exe
#CHICKEN_MAIN = test-multimap.scm
#CHICKEN_MAIN = runme.scm
#VARIANT = _static
all:: $(TARGET)
check: build
$(MAKE) -f $(TOP)/Makefile chicken_run
build: $(TARGET)
$(TARGET): $(INTERFACE) $(SRCS)
$(MAKE) -f $(TOP)/Makefile \
SRCS='$(SRCS)' CXXSRCS='$(CXXSRCS)' CHICKEN_MAIN='$(CHICKEN_MAIN)' \
INCLUDE='$(INCLUDE)' SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' \
SWIG='$(SWIG)' INTERFACE='$(INTERFACE)' CHICKENOPTS='$(CHICKENOPTS)' chicken$(VARIANT)
SRCS='$(SRCS)' CXXSRCS='$(CXXSRCS)' CHICKEN_MAIN='$(CHICKEN_MAIN)' \
INCLUDE='$(INCLUDE)' SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' \
SWIG='$(SWIG)' INTERFACE='$(INTERFACE)' CHICKENOPTS='$(CHICKENOPTS)' chicken$(VARIANT)
clean::
clean:
$(MAKE) -f $(TOP)/Makefile chicken_clean
rm -f example.scm
rm -f $(TARGET)
check::
env LD_LIBRARY_PATH=.:$$LD_LIBRARY_PATH csi test-multimap.scm

1
Examples/chicken/multimap/test-multimap.scm → Examples/chicken/multimap/runme.scm
View file

@ -1,4 +1,3 @@
;; run with './multimap test-multimap.scm'
;; feel free to uncomment and comment sections
(load-library 'example "multimap.so")

18
Examples/chicken/overload/Makefile
View file

@ -10,21 +10,21 @@ CFLAGS =
VARIANT =
# uncomment the following lines to build a static exe
#CHICKEN_MAIN = test-overload.scm
#CHICKEN_MAIN = runme.scm
#VARIANT = _static
all:: $(TARGET)
check: build
$(MAKE) -f $(TOP)/Makefile chicken_run
build: $(TARGET)
$(TARGET): $(INTERFACE) $(SRCS)
$(MAKE) -f $(TOP)/Makefile \
SRCS='$(SRCS)' CXXSRCS='$(CXXSRCS)' CHICKEN_MAIN='$(CHICKEN_MAIN)' \
INCLUDE='$(INCLUDE)' SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' \
SWIG='$(SWIG)' INTERFACE='$(INTERFACE)' CHICKENOPTS='$(CHICKENOPTS)' chicken$(VARIANT)_cpp
SRCS='$(SRCS)' CXXSRCS='$(CXXSRCS)' CHICKEN_MAIN='$(CHICKEN_MAIN)' \
INCLUDE='$(INCLUDE)' SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' \
SWIG='$(SWIG)' INTERFACE='$(INTERFACE)' CHICKENOPTS='$(CHICKENOPTS)' chicken$(VARIANT)_cpp
clean::
clean:
$(MAKE) -f $(TOP)/Makefile chicken_clean
rm -f example.scm
rm -f $(TARGET)
check::
env LD_LIBRARY_PATH=.:$$LD_LIBRARY_PATH csi test-overload.scm

0
Examples/chicken/overload/test-overload.scm → Examples/chicken/overload/runme.scm
View file

18
Examples/chicken/simple/Makefile
View file

@ -10,21 +10,21 @@ CFLAGS =
VARIANT =
# uncomment the following two lines to build a static exe
#CHICKEN_MAIN = test-simple.scm
#CHICKEN_MAIN = runme.scm
#VARIANT = _static
all:: $(TARGET)
check: build
$(MAKE) -f $(TOP)/Makefile chicken_run
build: $(TARGET)
$(TARGET): $(INTERFACE) $(SRCS)
$(MAKE) -f $(TOP)/Makefile \
SRCS='$(SRCS)' CXXSRCS='$(CXXSRCS)' CHICKEN_MAIN='$(CHICKEN_MAIN)' \
INCLUDE='$(INCLUDE)' SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' \
SWIG='$(SWIG)' INTERFACE='$(INTERFACE)' CHICKENOPTS='$(CHICKENOPTS)' chicken$(VARIANT)
SRCS='$(SRCS)' CXXSRCS='$(CXXSRCS)' CHICKEN_MAIN='$(CHICKEN_MAIN)' \
INCLUDE='$(INCLUDE)' SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' \
SWIG='$(SWIG)' INTERFACE='$(INTERFACE)' CHICKENOPTS='$(CHICKENOPTS)' chicken$(VARIANT)
clean::
clean:
$(MAKE) -f $(TOP)/Makefile chicken_clean
rm -f example.scm example-generic.scm example-clos.scm
rm -f $(TARGET)
check::
env LD_LIBRARY_PATH=.:$$LD_LIBRARY_PATH csi test-simple.scm

0
Examples/chicken/simple/test-simple.scm → Examples/chicken/simple/runme.scm
View file

9
Examples/csharp/arrays/Makefile
View file

@ -7,14 +7,13 @@ SWIGOPT =
CSHARPSRCS = *.cs
CSHARPFLAGS= -nologo -unsafe -out:runme.exe
all:: csharp
check: build
$(MAKE) -f $(TOP)/Makefile csharp_run
csharp::
build:
$(MAKE) -f $(TOP)/Makefile SRCS='$(SRCS)' SWIG='$(SWIG)' \
SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' csharp
$(MAKE) -f $(TOP)/Makefile CSHARPSRCS='$(CSHARPSRCS)' CSHARPFLAGS='$(CSHARPFLAGS)' csharp_compile
clean::
clean:
$(MAKE) -f $(TOP)/Makefile csharp_clean
check: all

9
Examples/csharp/callback/Makefile
View file

@ -7,14 +7,13 @@ SWIGOPT =
CSHARPSRCS = *.cs
CSHARPFLAGS= -debug -nologo -out:runme.exe
all:: csharp
check: build
$(MAKE) -f $(TOP)/Makefile csharp_run
csharp::
build:
$(MAKE) -f $(TOP)/Makefile CXXSRCS='$(CXXSRCS)' SWIG='$(SWIG)' \
SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' csharp_cpp
$(MAKE) -f $(TOP)/Makefile CSHARPSRCS='$(CSHARPSRCS)' CSHARPFLAGS='$(CSHARPFLAGS)' csharp_compile
clean::
clean:
$(MAKE) -f $(TOP)/Makefile csharp_clean
check: all

9
Examples/csharp/class/Makefile
View file

@ -7,14 +7,13 @@ SWIGOPT =
CSHARPSRCS = *.cs
CSHARPFLAGS= -nologo -out:runme.exe
all:: csharp
check: build
$(MAKE) -f $(TOP)/Makefile csharp_run
csharp::
build:
$(MAKE) -f $(TOP)/Makefile CXXSRCS='$(CXXSRCS)' SWIG='$(SWIG)' \
SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' csharp_cpp
$(MAKE) -f $(TOP)/Makefile CSHARPSRCS='$(CSHARPSRCS)' CSHARPFLAGS='$(CSHARPFLAGS)' csharp_compile
clean::
clean:
$(MAKE) -f $(TOP)/Makefile csharp_clean
check: all

9
Examples/csharp/enum/Makefile
View file

@ -7,14 +7,13 @@ SWIGOPT =
CSHARPSRCS = *.cs
CSHARPFLAGS= -nologo -out:runme.exe
all:: csharp
check: build
$(MAKE) -f $(TOP)/Makefile csharp_run
csharp::
build:
$(MAKE) -f $(TOP)/Makefile CXXSRCS='$(CXXSRCS)' SWIG='$(SWIG)' \
SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' csharp_cpp
$(MAKE) -f $(TOP)/Makefile CSHARPSRCS='$(CSHARPSRCS)' CSHARPFLAGS='$(CSHARPFLAGS)' csharp_compile
clean::
clean:
$(MAKE) -f $(TOP)/Makefile csharp_clean
check: all

9
Examples/csharp/extend/Makefile
View file

@ -7,14 +7,13 @@ SWIGOPT =
CSHARPSRCS = *.cs
CSHARPFLAGS= -nologo -out:runme.exe
all:: csharp
check: build
$(MAKE) -f $(TOP)/Makefile csharp_run
csharp::
build:
$(MAKE) -f $(TOP)/Makefile CXXSRCS='$(CXXSRCS)' SWIG='$(SWIG)' \
SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' csharp_cpp
$(MAKE) -f $(TOP)/Makefile CSHARPSRCS='$(CSHARPSRCS)' CSHARPFLAGS='$(CSHARPFLAGS)' csharp_compile
clean::
clean:
$(MAKE) -f $(TOP)/Makefile csharp_clean
check: all

9
Examples/csharp/funcptr/Makefile
View file

@ -7,14 +7,13 @@ SWIGOPT =
CSHARPSRCS = *.cs
CSHARPFLAGS= -nologo -out:runme.exe
all:: csharp
check: build
$(MAKE) -f $(TOP)/Makefile csharp_run
csharp::
build:
$(MAKE) -f $(TOP)/Makefile SRCS='$(SRCS)' SWIG='$(SWIG)' \
SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' csharp
$(MAKE) -f $(TOP)/Makefile CSHARPSRCS='$(CSHARPSRCS)' CSHARPFLAGS='$(CSHARPFLAGS)' csharp_compile
clean::
clean:
$(MAKE) -f $(TOP)/Makefile csharp_clean
check: all

9
Examples/csharp/reference/Makefile
View file

@ -7,14 +7,13 @@ SWIGOPT =
CSHARPSRCS = *.cs
CSHARPFLAGS= -nologo -out:runme.exe
all:: csharp
check: build
$(MAKE) -f $(TOP)/Makefile csharp_run
csharp::
build:
$(MAKE) -f $(TOP)/Makefile CXXSRCS='$(CXXSRCS)' SWIG='$(SWIG)' \
SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' csharp_cpp
$(MAKE) -f $(TOP)/Makefile CSHARPSRCS='$(CSHARPSRCS)' CSHARPFLAGS='$(CSHARPFLAGS)' csharp_compile
clean::
clean:
$(MAKE) -f $(TOP)/Makefile csharp_clean
check: all

9
Examples/csharp/simple/Makefile
View file

@ -7,14 +7,13 @@ SWIGOPT =
CSHARPSRCS = *.cs
CSHARPFLAGS= -nologo -out:runme.exe
all:: csharp
check: build
$(MAKE) -f $(TOP)/Makefile csharp_run
csharp::
build:
$(MAKE) -f $(TOP)/Makefile SRCS='$(SRCS)' SWIG='$(SWIG)' \
SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' csharp
$(MAKE) -f $(TOP)/Makefile CSHARPSRCS='$(CSHARPSRCS)' CSHARPFLAGS='$(CSHARPFLAGS)' csharp_compile
clean::
clean:
$(MAKE) -f $(TOP)/Makefile csharp_clean
check: all

9
Examples/csharp/template/Makefile
View file

@ -7,14 +7,13 @@ SWIGOPT =
CSHARPSRCS = *.cs
CSHARPFLAGS= -nologo -out:runme.exe
all:: csharp
check: build
$(MAKE) -f $(TOP)/Makefile csharp_run
csharp::
build:
$(MAKE) -f $(TOP)/Makefile CXXSRCS='$(CXXSRCS)' SWIG='$(SWIG)' \
SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' csharp_cpp
$(MAKE) -f $(TOP)/Makefile CSHARPSRCS='$(CSHARPSRCS)' CSHARPFLAGS='$(CSHARPFLAGS)' csharp_compile
clean::
clean:
$(MAKE) -f $(TOP)/Makefile csharp_clean
check: all

9
Examples/csharp/variables/Makefile
View file

@ -7,14 +7,13 @@ SWIGOPT =
CSHARPSRCS = *.cs
CSHARPFLAGS= -nologo -out:runme.exe
all:: csharp
check: build
$(MAKE) -f $(TOP)/Makefile csharp_run
csharp::
build:
$(MAKE) -f $(TOP)/Makefile SRCS='$(SRCS)' SWIG='$(SWIG)' \
SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' csharp
$(MAKE) -f $(TOP)/Makefile CSHARPSRCS='$(CSHARPSRCS)' CSHARPFLAGS='$(CSHARPFLAGS)' csharp_compile
clean::
clean:
$(MAKE) -f $(TOP)/Makefile csharp_clean
check: all

13
Examples/d/callback/Makefile
View file

@ -13,18 +13,15 @@ SWIGOPT =
DSRCS = *.d
DFLAGS = -ofrunme
check: build
cd $(WORKING_DIR); \
$(MAKE) -f $(TOP)/Makefile d_run
all:: d
d::
build:
cd $(WORKING_DIR); \
$(MAKE) -f $(TOP)/Makefile EXTRA_CFLAGS='$(EXTRA_CFLAGS)' EXTRA_LDFLAGS='$(EXTRA_LDFLAGS)' SWIG='$(SWIG)' SWIGOPT='$(SWIGOPT) -outcurrentdir ../example.i' TARGET='$(TARGET)' d_cpp; \
$(MAKE) -f $(TOP)/Makefile DSRCS='$(DSRCS)' DFLAGS='$(DFLAGS)' d_compile
clean::
clean:
cd $(WORKING_DIR); \
$(MAKE) -f $(TOP)/Makefile d_clean
check: all
cd $(WORKING_DIR); \
$(MAKE) -f $(TOP)/Makefile d_run

13
Examples/d/class/Makefile
View file

@ -13,18 +13,15 @@ SWIGOPT =
DSRCS = *.d
DFLAGS = -ofrunme
check: build
cd $(WORKING_DIR); \
$(MAKE) -f $(TOP)/Makefile d_run
all:: d
d::
build:
cd $(WORKING_DIR); \
$(MAKE) -f $(TOP)/Makefile EXTRA_CFLAGS='$(EXTRA_CFLAGS)' EXTRA_LDFLAGS='$(EXTRA_LDFLAGS)' SWIG='$(SWIG)' SWIGOPT='$(SWIGOPT) -outcurrentdir ../example.i' TARGET='$(TARGET)' d_cpp; \
$(MAKE) -f $(TOP)/Makefile DSRCS='$(DSRCS)' DFLAGS='$(DFLAGS)' d_compile
clean::
clean:
cd $(WORKING_DIR); \
$(MAKE) -f $(TOP)/Makefile d_clean
check: all
cd $(WORKING_DIR); \
$(MAKE) -f $(TOP)/Makefile d_run

13
Examples/d/constants/Makefile
View file

@ -13,18 +13,15 @@ SWIGOPT =
DSRCS = *.d
DFLAGS = -ofrunme
check: build
cd $(WORKING_DIR); \
$(MAKE) -f $(TOP)/Makefile d_run
all:: d
d::
build:
cd $(WORKING_DIR); \
$(MAKE) -f $(TOP)/Makefile EXTRA_CFLAGS='$(EXTRA_CFLAGS)' EXTRA_LDFLAGS='$(EXTRA_LDFLAGS)' SWIG='$(SWIG)' SWIGOPT='$(SWIGOPT) -outcurrentdir ../example.i' TARGET='$(TARGET)' d; \
$(MAKE) -f $(TOP)/Makefile DSRCS='$(DSRCS)' DFLAGS='$(DFLAGS)' d_compile
clean::
clean:
cd $(WORKING_DIR); \
$(MAKE) -f $(TOP)/Makefile d_clean
check: all
cd $(WORKING_DIR); \
$(MAKE) -f $(TOP)/Makefile d_run

13
Examples/d/enum/Makefile
View file

@ -13,18 +13,15 @@ SWIGOPT =
DSRCS = *.d
DFLAGS = -ofrunme
check: build
cd $(WORKING_DIR); \
$(MAKE) -f $(TOP)/Makefile d_run
all:: d
d::
build:
cd $(WORKING_DIR); \
$(MAKE) -f $(TOP)/Makefile EXTRA_CFLAGS='$(EXTRA_CFLAGS)' EXTRA_LDFLAGS='$(EXTRA_LDFLAGS)' SWIG='$(SWIG)' SWIGOPT='$(SWIGOPT) -outcurrentdir ../example.i' TARGET='$(TARGET)' d_cpp; \
$(MAKE) -f $(TOP)/Makefile DSRCS='$(DSRCS)' DFLAGS='$(DFLAGS)' d_compile
clean::
clean:
cd $(WORKING_DIR); \
$(MAKE) -f $(TOP)/Makefile d_clean
check: all
cd $(WORKING_DIR); \
$(MAKE) -f $(TOP)/Makefile d_run

13
Examples/d/extend/Makefile
View file

@ -13,18 +13,15 @@ SWIGOPT =
DSRCS = *.d
DFLAGS = -ofrunme
check: build
cd $(WORKING_DIR); \
$(MAKE) -f $(TOP)/Makefile d_run
all:: d
d::
build:
cd $(WORKING_DIR); \
$(MAKE) -f $(TOP)/Makefile EXTRA_CFLAGS='$(EXTRA_CFLAGS)' EXTRA_LDFLAGS='$(EXTRA_LDFLAGS)' SWIG='$(SWIG)' SWIGOPT='$(SWIGOPT) -outcurrentdir ../example.i' TARGET='$(TARGET)' d_cpp; \
$(MAKE) -f $(TOP)/Makefile DSRCS='$(DSRCS)' DFLAGS='$(DFLAGS)' d_compile
clean::
clean:
cd $(WORKING_DIR); \
$(MAKE) -f $(TOP)/Makefile d_clean
check: all
cd $(WORKING_DIR); \
$(MAKE) -f $(TOP)/Makefile d_run

13
Examples/d/funcptr/Makefile
View file

@ -13,18 +13,15 @@ SWIGOPT =
DSRCS = *.d
DFLAGS = -ofrunme
check: build
cd $(WORKING_DIR); \
$(MAKE) -f $(TOP)/Makefile d_run
all:: d
d::
build:
cd $(WORKING_DIR); \
$(MAKE) -f $(TOP)/Makefile EXTRA_CFLAGS='$(EXTRA_CFLAGS)' EXTRA_LDFLAGS='$(EXTRA_LDFLAGS)' EXTRA_LDFLAGS='$(EXTRA_LDFLAGS)' SWIG='$(SWIG)' SWIGOPT='$(SWIGOPT) -outcurrentdir ../example.i' TARGET='$(TARGET)' d; \
$(MAKE) -f $(TOP)/Makefile DSRCS='$(DSRCS)' DFLAGS='$(DFLAGS)' d_compile
clean::
clean:
cd $(WORKING_DIR); \
$(MAKE) -f $(TOP)/Makefile d_clean
check: all
cd $(WORKING_DIR); \
$(MAKE) -f $(TOP)/Makefile d_run

13
Examples/d/simple/Makefile
View file

@ -13,18 +13,15 @@ SWIGOPT =
DSRCS = *.d
DFLAGS = -ofrunme
check: build
cd $(WORKING_DIR); \
$(MAKE) -f $(TOP)/Makefile d_run
all:: d
d::
build:
cd $(WORKING_DIR); \
$(MAKE) -f $(TOP)/Makefile EXTRA_CFLAGS='$(EXTRA_CFLAGS)' EXTRA_LDFLAGS='$(EXTRA_LDFLAGS)' SWIG='$(SWIG)' SWIGOPT='$(SWIGOPT) -outcurrentdir ../example.i' TARGET='$(TARGET)' d; \
$(MAKE) -f $(TOP)/Makefile DSRCS='$(DSRCS)' DFLAGS='$(DFLAGS)' d_compile
clean::
clean:
cd $(WORKING_DIR); \
$(MAKE) -f $(TOP)/Makefile d_clean
check: all
cd $(WORKING_DIR); \
$(MAKE) -f $(TOP)/Makefile d_run

13
Examples/d/variables/Makefile
View file

@ -13,18 +13,15 @@ SWIGOPT =
DSRCS = *.d
DFLAGS = -ofrunme
check: build
cd $(WORKING_DIR); \
$(MAKE) -f $(TOP)/Makefile d_run
all:: d
d::
build:
cd $(WORKING_DIR); \
$(MAKE) -f $(TOP)/Makefile EXTRA_CFLAGS='$(EXTRA_CFLAGS)' EXTRA_LDFLAGS='$(EXTRA_LDFLAGS)' SWIG='$(SWIG)' SWIGOPT='$(SWIGOPT) -outcurrentdir ../example.i' TARGET='$(TARGET)' d; \
$(MAKE) -f $(TOP)/Makefile DSRCS='$(DSRCS)' DFLAGS='$(DFLAGS)' d_compile
clean::
clean:
cd $(WORKING_DIR); \
$(MAKE) -f $(TOP)/Makefile d_clean
check: all
cd $(WORKING_DIR); \
$(MAKE) -f $(TOP)/Makefile d_run

12
Examples/go/callback/Makefile
View file

@ -5,14 +5,12 @@ TARGET = example
INTERFACE = example.i
SWIGOPT =
all:: go
check: build
$(MAKE) -f $(TOP)/Makefile TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' go_run
go::
build:
$(MAKE) -f $(TOP)/Makefile CXXSRCS='$(CXXSRCS)' SWIG='$(SWIG)' \
SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' go_cpp
clean::
$(MAKE) -f $(TOP)/Makefile go_clean
check: all
$(MAKE) -f $(TOP)/Makefile TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' go_run
clean:
$(MAKE) -f $(TOP)/Makefile INTERFACE='$(INTERFACE)' go_clean

12
Examples/go/class/Makefile
View file

@ -5,12 +5,12 @@ TARGET = example
INTERFACE = example.i
LIBS = -lm
all::
check: build
$(MAKE) -f $(TOP)/Makefile TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' go_run
build:
$(MAKE) -f $(TOP)/Makefile CXXSRCS='$(CXXSRCS)' SWIG='$(SWIG)' \
TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' go_cpp
clean::
$(MAKE) -f $(TOP)/Makefile go_clean
check: all
$(MAKE) -f $(TOP)/Makefile TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' go_run
clean:
$(MAKE) -f $(TOP)/Makefile INTERFACE='$(INTERFACE)' go_clean

12
Examples/go/constants/Makefile
View file

@ -5,12 +5,12 @@ TARGET = example
INTERFACE = example.i
SWIGOPT =
all::
check: build
$(MAKE) -f $(TOP)/Makefile TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' go_run
build:
$(MAKE) -f $(TOP)/Makefile CXXSRCS='$(CXXSRCS)' SWIG='$(SWIG)' \
SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' go
clean::
$(MAKE) -f $(TOP)/Makefile go_clean
check: all
$(MAKE) -f $(TOP)/Makefile TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' go_run
clean:
$(MAKE) -f $(TOP)/Makefile INTERFACE='$(INTERFACE)' go_clean

12
Examples/go/enum/Makefile
View file

@ -5,14 +5,12 @@ TARGET = example
INTERFACE = example.i
SWIGOPT =
all:: go
check: build
$(MAKE) -f $(TOP)/Makefile TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' go_run
go::
build:
$(MAKE) -f $(TOP)/Makefile CXXSRCS='$(CXXSRCS)' SWIG='$(SWIG)' \
SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' go_cpp
clean::
$(MAKE) -f $(TOP)/Makefile go_clean
check: all
$(MAKE) -f $(TOP)/Makefile TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' go_run
clean:
$(MAKE) -f $(TOP)/Makefile INTERFACE='$(INTERFACE)' go_clean

12
Examples/go/extend/Makefile
View file

@ -5,14 +5,12 @@ TARGET = example
INTERFACE = example.i
SWIGOPT =
all:: go
check: build
$(MAKE) -f $(TOP)/Makefile TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' go_run
go::
build:
$(MAKE) -f $(TOP)/Makefile CXXSRCS='$(CXXSRCS)' SWIG='$(SWIG)' \
SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' go_cpp
clean::
$(MAKE) -f $(TOP)/Makefile go_clean
check: all
$(MAKE) -f $(TOP)/Makefile TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' go_run
clean:
$(MAKE) -f $(TOP)/Makefile INTERFACE='$(INTERFACE)' go_clean

12
Examples/go/funcptr/Makefile
View file

@ -5,14 +5,12 @@ TARGET = example
INTERFACE = example.i
SWIGOPT =
all:: go
check: build
$(MAKE) -f $(TOP)/Makefile TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' go_run
go::
build:
$(MAKE) -f $(TOP)/Makefile SRCS='$(SRCS)' SWIG='$(SWIG)' \
SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' go
clean::
$(MAKE) -f $(TOP)/Makefile go_clean
check: all
$(MAKE) -f $(TOP)/Makefile TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' go_run
clean:
$(MAKE) -f $(TOP)/Makefile INTERFACE='$(INTERFACE)' go_clean

12
Examples/go/multimap/Makefile
View file

@ -5,14 +5,12 @@ TARGET = example
INTERFACE = example.i
SWIGOPT =
all:: go
check: build
$(MAKE) -f $(TOP)/Makefile TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' go_run
go::
build:
$(MAKE) -f $(TOP)/Makefile SRCS='$(SRCS)' SWIG='$(SWIG)' \
SWIGOPT='$(SWIGOPT)' TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' go
clean::
$(MAKE) -f $(TOP)/Makefile go_clean
check: all
$(MAKE) -f $(TOP)/Makefile TARGET='$(TARGET)' INTERFACE='$(INTERFACE)' go_run
clean:
$(MAKE) -f $(TOP)/Makefile INTERFACE='$(INTERFACE)' go_clean

Some files were not shown because too many files have changed in this diff Show more