Merge branch 'swig:master' into imfunc
This commit is contained in:
LindleyF
GitHub
commit
e25911b846
308 changed files with 5008 additions and 4773 deletions
|
|
@ -441,12 +441,12 @@ Resulting output:
|
|||
|
||||
<blockquote>
|
||||
<pre>
|
||||
hash len: 5
|
||||
get: hashval2
|
||||
hash item: hashval5 [h5]
|
||||
hash item: hashval1 [h1]
|
||||
hash item: hashval2 [h2]
|
||||
hash item: hashval3 [h3]
|
||||
list len: 5
|
||||
get: listval2
|
||||
list item: newlistval1
|
||||
list item: listval2
|
||||
list item: listval3
|
||||
list item: listval5
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
|
|
@ -494,12 +494,12 @@ Resulting output:
|
|||
|
||||
<blockquote>
|
||||
<pre>
|
||||
list len: 5
|
||||
get: listval2
|
||||
list item: newlistval1
|
||||
list item: listval2
|
||||
list item: listval3
|
||||
list item: listval5
|
||||
hash len: 5
|
||||
get: hashval2
|
||||
hash item: hashval5 [h5]
|
||||
hash item: hashval1 [h1]
|
||||
hash item: hashval2 [h2]
|
||||
hash item: hashval3 [h3]
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
|
|
|
|||
|
|
@ -144,14 +144,39 @@ When either of these is used from a target language, a runtime call is made to o
|
|||
<H3><a name="CPlusPlus11_extern_template">7.2.3 Extern template</a></H3>
|
||||
|
||||
|
||||
<p>SWIG correctly parses the keywords <tt>extern template</tt>.
|
||||
<p>SWIG correctly parses <tt>extern template</tt> explicit instantiation declarations.
|
||||
However, this template instantiation suppression in a translation unit has no relevance outside of the C++ compiler and so is not used by SWIG.
|
||||
SWIG only uses <tt>%template</tt> for instantiating and wrapping templates.</p>
|
||||
SWIG only uses <tt>%template</tt> for instantiating and wrapping templates.
|
||||
Consider the class template below:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
template class std::vector<int>; // C++03 explicit instantiation in C++
|
||||
extern template class std::vector<int>; // C++11 explicit instantiation suppression in C++
|
||||
%template(VectorInt) std::vector<int>; // SWIG instantiation
|
||||
// Class template
|
||||
template class std::vector<int>; // C++03 template explicit instantiation definition in C++
|
||||
extern template class std::vector<int>; // C++11 template explicit instantiation declaration (extern template)
|
||||
%template(VectorInt) std::vector<int>; // SWIG template instantiation
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
The above result in warnings:
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
example.i:2: Warning 320: Explicit template instantiation ignored.
|
||||
example.i:3: Warning 327: Extern template ignored.
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Similarly for the function template below:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
// Function template
|
||||
template void Func<int>(); // C++03 template explicit instantiation definition in C++
|
||||
extern template void Func<int>(); // C++11 template explicit instantiation declaration (extern template)
|
||||
%template(FuncInt) Func<int>; // SWIG template instantiation
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="CPlusPlus11_initializer_lists">7.2.4 Initializer lists</a></H3>
|
||||
|
|
|
|||
|
|
@ -91,17 +91,16 @@
|
|||
</ul>
|
||||
<li><a href="Windows.html#Windows_other_compilers">Instructions for using the Examples with other compilers</a>
|
||||
</ul>
|
||||
<li><a href="Windows.html#Windows_cygwin_mingw">SWIG on Cygwin and MinGW</a>
|
||||
<ul>
|
||||
<li><a href="Windows.html#Windows_swig_exe">Building swig.exe on Windows</a>
|
||||
<ul>
|
||||
<li><a href="Windows.html#Windows_cmake">Building swig.exe using CMake</a>
|
||||
<li><a href="Windows.html#Windows_mingw_msys">Building swig.exe using MSYS2</a>
|
||||
<li><a href="Windows.html#Windows_msys2">Building swig.exe using MSYS2</a>
|
||||
<li><a href="Windows.html#Windows_mingw_msys">Building swig.exe using MinGW and MSYS</a>
|
||||
<li><a href="Windows.html#Windows_cygwin">Building swig.exe using Cygwin</a>
|
||||
</ul>
|
||||
<ul>
|
||||
<li><a href="Windows.html#Windows_examples_cygwin">Running the examples on Windows using Cygwin</a>
|
||||
</ul>
|
||||
</ul>
|
||||
<li><a href="Windows.html#Windows_interface_file">Microsoft extensions and other Windows quirks</a>
|
||||
</ul>
|
||||
</div>
|
||||
|
|
@ -172,6 +171,7 @@
|
|||
<li><a href="SWIG.html#SWIG_rename_ignore">Renaming and ignoring declarations</a>
|
||||
<ul>
|
||||
<li><a href="SWIG.html#SWIG_nn29">Simple renaming of specific identifiers</a>
|
||||
<li><a href="SWIG.html#SWIG_ignore">Ignoring identifiers</a>
|
||||
<li><a href="SWIG.html#SWIG_advanced_renaming">Advanced renaming support</a>
|
||||
<li><a href="SWIG.html#SWIG_limiting_renaming">Limiting global renaming rules</a>
|
||||
<li><a href="SWIG.html#SWIG_chosen_unignore">Ignoring everything then wrapping a few selected symbols</a>
|
||||
|
|
@ -251,6 +251,9 @@
|
|||
</ul>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_nn28">Overloaded operators</a>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_class_extension">Class extension</a>
|
||||
<ul>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_replacing_methods">Replacing class methods</a>
|
||||
</ul>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_nn30">Templates</a>
|
||||
<ul>
|
||||
<li><a href="SWIGPlus.html#SWIGPlus_template_directive">The %template directive</a>
|
||||
|
|
|
|||
|
|
@ -1354,7 +1354,7 @@ Here is the list of all Doxygen tags and the description of how they are transla
|
|||
</tr>
|
||||
<tr>
|
||||
<td>\throws</td>
|
||||
<td>replaced wih ':raises:'</td>
|
||||
<td>replaced with ':raises:'</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>\todo</td>
|
||||
|
|
|
|||
|
|
@ -3613,7 +3613,7 @@ A target language is given the 'Supported' status when
|
|||
Examples must be available and run successfully.
|
||||
</li>
|
||||
<li>
|
||||
The examples and test-suite must be fully functioning on the Travis Continuous Integration platform.
|
||||
The examples and test-suite must be fully functioning on the Github Actions Continuous Integration platform.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
|
|
@ -3660,9 +3660,9 @@ Some minimum requirements and notes about languages with the 'Experimental' stat
|
|||
The number of tests in these lists should be no greater than half of the number of tests in the full test-suite.
|
||||
</li>
|
||||
<li>
|
||||
The examples and test-suite must also be fully functioning on the Travis Continuous Integration platform.
|
||||
However, experimental languages will be set as 'allow_failures'.
|
||||
This means that pull requests and normal development commits will not break the entire Travis build should an experimental language fail.
|
||||
The examples and test-suite must also be fully functioning on the Github Actions Continuous Integration platform.
|
||||
However, experimental languages will be flagged as 'continue-on-error'.
|
||||
This means that pull requests and normal development commits will not break the entire Github Actions build should an experimental language fail.
|
||||
</li>
|
||||
<li>
|
||||
Any new failed tests will be fixed on a 'best effort' basis by core developers with no promises made.
|
||||
|
|
|
|||
|
|
@ -71,6 +71,7 @@ code. SWIG fills this gap.
|
|||
There are (at least) two different Go compilers. The first is the gc compiler
|
||||
of the <a href="https://golang.org/doc/install">Go distribution</a>, normally
|
||||
invoked via the <a href="https://golang.org/cmd/go/">go tool</a>.
|
||||
SWIG supports the gc compiler version 1.2 or later.
|
||||
The second Go compiler is the <a href="https://golang.org/doc/install/gccgo">
|
||||
gccgo compiler</a>, which is a frontend to the GCC compiler suite.
|
||||
The interface to C/C++ code is completely different for the two Go compilers.
|
||||
|
|
@ -142,44 +143,6 @@ You will now have a Go package that you can import from other Go packages as
|
|||
usual.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
SWIG can be used without cgo, via the <tt>-no-cgo</tt> option, but
|
||||
more steps are required. This only works with Go versions before 1.5.
|
||||
When using Go version 1.2 or later, or when using gccgo, the code
|
||||
generated by SWIG can be linked directly into the Go program. A
|
||||
typical command sequence when using the Go compiler of the Go
|
||||
distribution would look like this:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
% swig -go -no-cgo example.i
|
||||
% gcc -c code.c # The C library being wrapped.
|
||||
% gcc -c example_wrap.c
|
||||
% go tool 6g example.go
|
||||
% go tool 6c example_gc.c
|
||||
% go tool pack grc example.a example.6 example_gc.6 code.o example_wrap.o
|
||||
% go tool 6g main.go
|
||||
% go tool 6l main.6
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
You can also put the wrapped code into a shared library, and when using the Go
|
||||
versions before 1.2 this is the only supported option. A typical command
|
||||
sequence for this approach would look like this:
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
% swig -go -no-cgo -use-shlib example.i
|
||||
% gcc -c -fpic example.c
|
||||
% gcc -c -fpic example_wrap.c
|
||||
% gcc -shared example.o example_wrap.o -o example.so
|
||||
% go tool 6g example.go
|
||||
% go tool 6c example_gc.c
|
||||
% go tool pack grc example.a example.6 example_gc.6
|
||||
% go tool 6g main.go # your code, not generated by SWIG
|
||||
% go tool 6l main.6
|
||||
</pre></div>
|
||||
|
||||
|
||||
<H3><a name="Go_commandline">25.3.1 Go-specific Commandline Options</a></H3>
|
||||
|
||||
|
|
@ -206,9 +169,7 @@ swig -go -help
|
|||
|
||||
<tr>
|
||||
<td>-no-cgo</td>
|
||||
<td>Generate files that can be used directly, rather than via the Go
|
||||
cgo tool. This option does not work with Go 1.5 or later. It is
|
||||
required for versions of Go before 1.2.</td>
|
||||
<td>This option is no longer supported.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
|
|
@ -279,13 +240,10 @@ swig -go -help
|
|||
<H3><a name="Go_outputs">25.3.2 Generated Wrapper Files</a></H3>
|
||||
|
||||
|
||||
<p>There are two different approaches to generating wrapper files,
|
||||
controlled by SWIG's <tt>-no-cgo</tt> option. The <tt>-no-cgo</tt>
|
||||
option only works with version of Go before 1.5. It is required
|
||||
when using versions of Go before 1.2.</p>
|
||||
|
||||
<p>With or without the <tt>-no-cgo</tt> option, SWIG will generate the
|
||||
following files when generating wrapper code:</p>
|
||||
<p>
|
||||
SWIG will generate the following files when generating wrapper
|
||||
code:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
|
|
@ -308,17 +266,6 @@ or C++ compiler.
|
|||
</li>
|
||||
</ul>
|
||||
|
||||
<p>When the <tt>-no-cgo</tt> option is used, and the <tt>-gccgo</tt>
|
||||
option is not used, SWIG will also generate an additional file:</p>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
MODULE_gc.c will contain C code which should be compiled with the C
|
||||
compiler distributed as part of the gc compiler. It should then be
|
||||
combined with the compiled MODULE.go using go tool pack.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
|
||||
<H2><a name="Go_basic_tour">25.4 A tour of basic C/C++ wrapping</a></H2>
|
||||
|
||||
|
|
|
|||
|
|
@ -9067,6 +9067,11 @@ You may have to add in some "jtype", "jstype", "javain" and "javaout" typemaps w
|
|||
Here the default typemaps work for <tt>int</tt> and <tt>char *</tt>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Note that if you're wanting to effectively <b>replace</b> the JNI code generated for a C/C++ function then you'll need to use <tt>%ignore</tt> as well
|
||||
to tell SWIG not to automatically generate a JNI wrapper for it.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In summary the <tt>%native</tt> directive is telling SWIG to generate the Java code to access the JNI C code, but not the JNI C function itself.
|
||||
This directive is only really useful if you want to mix your own hand crafted JNI code and the SWIG generated code into one Java class or package.
|
||||
|
|
@ -9100,7 +9105,7 @@ This method normally calls the C++ destructor or <tt>free()</tt> for C code.
|
|||
<p>
|
||||
The generated code can be debugged using both a Java debugger and a C++ debugger using the usual debugging techniques.
|
||||
Breakpoints can be set in either Java or C++ code and so both can be debugged simultaneously.
|
||||
Most debuggers do not understand both Java and C++, with one noteable exception of Sun Studio,
|
||||
Most debuggers do not understand both Java and C++, with one notable exception of Sun Studio,
|
||||
where it is possible to step from Java code into a JNI method within one environment.
|
||||
</p>
|
||||
|
||||
|
|
|
|||
|
|
@ -89,24 +89,10 @@ $ swig -javascript -jsc example.i</pre>
|
|||
<pre>
|
||||
$ swig -c++ -javascript -jsc example.i</pre>
|
||||
</div>
|
||||
<p>The V8 code that SWIG generates should work with most versions from 3.11.10.
|
||||
However, the only early version that receives some testing is 3.14.5, which is
|
||||
still shipped with Ubuntu for some reason. Other than that it's probably safer
|
||||
to assume that versions earlier than 5.0 are no longer supported. Keep in mind
|
||||
that these are V8 versions, not Node.js. To give some perspective, Node.js v6.0
|
||||
<p>The V8 code that SWIG generates requires at least V8 5.0. Keep in mind
|
||||
that this is theV8 version, not Node.js. To give some perspective, Node.js v6.0
|
||||
uses V8 5.0, v12.0 - 7.4, v14.0 - 8.1...</p>
|
||||
<p>The API headers for V8 >= 4.3.10 define constants which SWIG can use to
|
||||
determine the V8 version it is compiling for. For versions < 4.3.10, you
|
||||
need to specify the V8 version when running SWIG. This is specified as a hex
|
||||
constant, but the constant is read as pairs of decimal digits, so for V8
|
||||
3.25.30 use constant 0x032530. This scheme can't represent components > 99,
|
||||
but this constant is only useful for V8 < 4.3.10, and no V8 versions from
|
||||
that era had a component > 99. For example:</p>
|
||||
<div class="shell">
|
||||
<pre>
|
||||
$ swig -c++ -javascript -v8 -DV8_VERSION=0x032530 example.i</pre>
|
||||
</div>
|
||||
<p>If you're targeting V8 >= 4.3.10, you would just run swig like so:</p>
|
||||
<p>To generate code for V8, you would run swig like so:</p>
|
||||
<div class="shell">
|
||||
<pre>
|
||||
$ swig -c++ -javascript -v8 example.i</pre>
|
||||
|
|
|
|||
|
|
@ -720,7 +720,6 @@ Here's a simple example using Trolltech's Qt Library:
|
|||
class QApplication {
|
||||
public:
|
||||
QApplication( int argc, char **argv );
|
||||
void setMainWidget( QWidget *widget );
|
||||
void exec();
|
||||
};
|
||||
|
||||
|
|
@ -736,16 +735,15 @@ public:
|
|||
|
||||
|
||||
<div class="code"><pre>
|
||||
bash-2.05a$ QTPATH=/your/qt/path
|
||||
bash-2.05a$ for file in swig.mli swig.ml swigp4.ml ; do swig -ocaml -co $file ; done
|
||||
bash-2.05a$ ocamlc -c swig.mli ; ocamlc -c swig.ml
|
||||
bash-2.05a$ ocamlc -I `camlp4 -where` -pp "camlp4o pa_extend.cmo q_MLast.cmo" -c swigp4.ml
|
||||
bash-2.05a$ swig -ocaml -c++ -I$QTPATH/include qt.i
|
||||
bash-2.05a$ mv qt_wrap.cxx qt_wrap.c
|
||||
bash-2.05a$ ocamlc -c -ccopt -xc++ -ccopt -g -g -ccopt -I$QTPATH/include qt_wrap.c
|
||||
bash-2.05a$ ocamlc -c qt.mli
|
||||
bash-2.05a$ ocamlc -c qt.ml
|
||||
bash-2.05a$ ocamlmktop -custom swig.cmo -I `camlp4 -where` \
|
||||
$ QTPATH=/your/qt/path
|
||||
$ for file in swig.mli swig.ml swigp4.ml ; do swig -ocaml -co $file ; done
|
||||
$ ocamlc -c swig.mli ; ocamlc -c swig.ml
|
||||
$ ocamlc -I `camlp4 -where` -pp "camlp4o pa_extend.cmo q_MLast.cmo" -c swigp4.ml
|
||||
$ swig -ocaml -c++ -o qt_wrap.c qt.i
|
||||
$ ocamlc -c -ccopt -xc++ -ccopt -g -g -ccopt -I$QTPATH/include qt_wrap.c
|
||||
$ ocamlc -c qt.mli
|
||||
$ ocamlc -c qt.ml
|
||||
$ ocamlmktop -custom swig.cmo -I `camlp4 -where` \
|
||||
camlp4o.cma swigp4.cmo qt_wrap.o qt.cmo -o qt_top -cclib \
|
||||
-L$QTPATH/lib -cclib -lqt
|
||||
</pre></div>
|
||||
|
|
|
|||
|
|
@ -570,13 +570,13 @@ __mul__ a * b
|
|||
__div__ a / b
|
||||
__pow__ a ^ b
|
||||
__ldiv__ a \ b
|
||||
__lshift__ a << b
|
||||
__rshift__ a >> b
|
||||
__lt__ a < b
|
||||
__le__ a <= b
|
||||
__lshift__ a << b
|
||||
__rshift__ a >> b
|
||||
__lt__ a < b
|
||||
__le__ a <= b
|
||||
__eq__ a == b
|
||||
__ge__ a >= b
|
||||
__gt__ a > b
|
||||
__ge__ a >= b
|
||||
__gt__ a > b
|
||||
__ne__ a != b
|
||||
__el_mul__ a .* b
|
||||
__el_div__ a ./ b
|
||||
|
|
@ -598,16 +598,16 @@ On the C++ side, the default mappings are as follows:
|
|||
%rename(__mul__) *::operator*;
|
||||
%rename(__div__) *::operator/;
|
||||
%rename(__mod__) *::operator%;
|
||||
%rename(__lshift__) *::operator<<;
|
||||
%rename(__rshift__) *::operator>>;
|
||||
%rename(__lshift__) *::operator<<;
|
||||
%rename(__rshift__) *::operator>>;
|
||||
%rename(__el_and__) *::operator&&;
|
||||
%rename(__el_or__) *::operator||;
|
||||
%rename(__xor__) *::operator^;
|
||||
%rename(__invert__) *::operator~;
|
||||
%rename(__lt__) *::operator<;
|
||||
%rename(__le__) *::operator<=;
|
||||
%rename(__gt__) *::operator>;
|
||||
%rename(__ge__) *::operator>=;
|
||||
%rename(__lt__) *::operator<;
|
||||
%rename(__le__) *::operator<=;
|
||||
%rename(__gt__) *::operator>;
|
||||
%rename(__ge__) *::operator>=;
|
||||
%rename(__eq__) *::operator==;
|
||||
%rename(__ne__) *::operator!=;
|
||||
%rename(__not__) *::operator!;
|
||||
|
|
@ -634,7 +634,7 @@ You can use it to define special behavior, like for example defining Octave oper
|
|||
%extend A {
|
||||
string __str__() {
|
||||
stringstream sout;
|
||||
sout<<$self->value;
|
||||
sout<<$self->value;
|
||||
return sout.str();
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -91,10 +91,10 @@
|
|||
<p>
|
||||
This chapter describes SWIG's support of Perl5. Although the Perl5
|
||||
module is one of the earliest SWIG modules, it has continued to evolve
|
||||
and has been improved greatly with the help of SWIG users. For the
|
||||
best results, it is recommended that SWIG be used with Perl 5.8 or
|
||||
later. We're no longer testing regularly with older versions, but
|
||||
Perl 5.6 seems to mostly work, while older versions don't.
|
||||
and has been improved greatly with the help of SWIG users. As of SWIG
|
||||
4.1.0, the minimum version of Perl we aim to support is Perl 5.8.0.
|
||||
We can no longer easily test with older versions, and they no longer
|
||||
seem to be in active use.
|
||||
</p>
|
||||
|
||||
<H2><a name="Perl5_nn2">31.1 Overview</a></H2>
|
||||
|
|
@ -680,7 +680,6 @@ files(s) field".
|
|||
installation under "Additional include directories".
|
||||
|
||||
<li>Define the symbols WIN32 and MSWIN32 under preprocessor options.
|
||||
If using the ActiveWare port, also define the symbol PERL_OBJECT.
|
||||
Note that all extensions to the ActiveWare port must be compiled with
|
||||
the C++ compiler since Perl has been encapsulated in a C++ class.
|
||||
|
||||
|
|
@ -2651,8 +2650,8 @@ constructors and destructors for the package and are always named
|
|||
"new" and "DESTROY". The constructor always returns a tied hash
|
||||
table. This hash table is used to access the member variables of a
|
||||
structure in addition to being able to invoke member functions. The
|
||||
<tt>%OWNER</tt> and <tt>%BLESSEDMEMBERS</tt> hash tables are used
|
||||
internally and described shortly.
|
||||
<tt>%OWNER</tt> and <tt>%BLESSEDMEMBERS</tt> hash tables are
|
||||
implementation details used internally and described shortly.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
|
|
@ -2740,8 +2739,15 @@ to a C function that remembers the object, and then destroy the
|
|||
corresponding Perl object (this situation turns out to come up
|
||||
frequently when constructing objects like linked lists and trees).
|
||||
When C takes possession of an object, you can change Perl's ownership
|
||||
by simply deleting the object from the <tt>%OWNER</tt> hash. This is
|
||||
done using the <tt>DISOWN</tt> method.
|
||||
by calling the <tt>DISOWN</tt> method (which will delete the object
|
||||
from the internal <tt>%OWNER</tt> hash).
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The <tt>%OWNER</tt> hash is an implementation detail, discussed here
|
||||
only to help clarify the operation of <tt>ACQUIRE</tt> and <tt>DISOWN</tt>.
|
||||
You should not access <tt>%OWNER</tt> directly - the details of how it
|
||||
works (and possibly even its existence) may chance in future SWIG versions.
|
||||
</p>
|
||||
|
||||
<div class="targetlang"><pre>
|
||||
|
|
|
|||
|
|
@ -50,18 +50,19 @@
|
|||
|
||||
|
||||
<p>
|
||||
In this chapter, we discuss SWIG's support of PHP. SWIG currently supports
|
||||
generating wrappers for PHP7 and PHP8. Support for PHP5 was removed in SWIG
|
||||
4.0.0 and support for PHP4 was removed in SWIG 1.3.37.
|
||||
In this chapter, we discuss SWIG's support of PHP. Currently any PHP7 or PHP8
|
||||
release should work.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Currently any PHP7 or PHP8 release should work.
|
||||
Support for PHP7 was added in SWIG 3.0.11 and for PHP8 in 4.1.0.
|
||||
Support for PHP5 was removed in SWIG 4.0.0 and support for PHP4 was removed in
|
||||
SWIG 1.3.37. There never was a PHP6 release.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In order to use this module, you will need to have a copy of the PHP
|
||||
include files to compile the SWIG generated files. If you installed
|
||||
include files to compile the SWIG generated C/C++ sources. If you installed
|
||||
PHP from a binary package, you may need to install a "php-dev" or "php-devel"
|
||||
package for these to be installed. You can find out where these files are
|
||||
by running <tt>php-config --includes</tt>. To use the built PHP module you
|
||||
|
|
@ -161,7 +162,7 @@ default extension directory, you also need to specify the path, for example:
|
|||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
extension=/path/to/modulename.so
|
||||
extension=/path/to/modulename.so
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
|
|
@ -343,6 +344,80 @@ $c = bar(3.5); # Use default argument for 2nd parameter
|
|||
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
SWIG generates PHP type declarations for function parameters and return
|
||||
types for PHP 8 and later (we don't try to support PHP 7's more limited type
|
||||
declarations and the generated wrappers compiled for PHP 7 will not have any
|
||||
type declarations).
|
||||
</p>
|
||||
|
||||
<p>
|
||||
You can control the generation of PHP type declarations using
|
||||
the "php:type" %feature. This has three settings:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li> <p>If unset or set to "0" then no type declarations are generated, e.g.: <tt>%feature("php:type", "0");</tt>
|
||||
</p>
|
||||
</li>
|
||||
<li> <p>If set to "1" then type declarations are generated for both parameters and return types, e.g.: <tt>%feature("php:type", "1");</tt>
|
||||
</p></li>
|
||||
<li> <p>The default setting is "compat", which is the same as "1" except no
|
||||
return type declarations are generated for virtual methods for which
|
||||
directors are enabled. This provides better compatibility for PHP
|
||||
subclasses of wrapped virtual methods in existing SWIG-generated bindings, e.g.: <tt>%feature("php:type", "compat");</tt>
|
||||
</p></li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
If you have an existing PHP interface and are upgrading to SWIG >= 4.1.0
|
||||
then the default "compat" setting should work well.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
If you're writing a new set of bindings and <b>only targetting PHP8 or newer</b>
|
||||
then enabling type declarations everywhere probably makes sense. It will
|
||||
only actually make a difference if you enable directors and are wrapping C++
|
||||
classes with virtual methods, but doing it anyway means you won't forget to if
|
||||
the code you are wrapping later evolves to have such classes and methods.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The type declaration information will make the generated source code and
|
||||
compiler extension module larger, so you might want to turn off type
|
||||
declarations if keeping these small is important to you. If you find you
|
||||
need to turn off type declarations to fix a problem, please let us know
|
||||
via our github issue tracker.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Note that being a SWIG feature this can be specified globally (like above) or
|
||||
per class, per method, etc. See the <a
|
||||
href="Customization.html#Customization_features">%feature directives</a>
|
||||
section for full details of how to control at a fine-grained level.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The PHP type information is specified via a "phptype" attribute on "in" and
|
||||
"out" typemaps, and these have been added for all the typemaps we supply for
|
||||
PHP. We don't currently support this for "argout" templates, but probably
|
||||
will in a future version.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
If you have written custom SWIG typemaps for PHP and want to add PHP type
|
||||
declarations, then the syntax is very like how you'd specify the type in
|
||||
PHP code, e.g. <tt>%typemap(in, phptype="int|string|Foo")</tt> means the
|
||||
typemap accepts a PHP int or string or an object of class Foo,
|
||||
<tt>%typemap(in, phptype="?int")</tt> means a PHP int or NULL, etc.
|
||||
As well as the standard PHP type declaration types, SWIG also understands the
|
||||
special type "SWIGTYPE" as an entry in phptype, which means the PHP type
|
||||
corresponding to the type that this typemap matched on - for a object this
|
||||
will give you the PHP class for the object, and for a pointer to a non-class
|
||||
type it will give you the name of the PHP class SWIG created for that
|
||||
pointer type.
|
||||
</p>
|
||||
|
||||
<!-- This isn't correct for 1.3.30 and needs rewriting to reflect reality
|
||||
<p>
|
||||
Because PHP is a dynamically typed language, the default typemaps
|
||||
|
|
@ -426,6 +501,7 @@ taking the integer argument.
|
|||
|
||||
<H3><a name="Php_nn2_5">32.2.5 Pointers and References</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
Since SWIG 4.1.0, SWIG wraps C/C++ classes directly with PHP objects.
|
||||
Pointers to other types are also wrapped as PHP objects - mostly this is an
|
||||
|
|
@ -742,7 +818,10 @@ class Ko {
|
|||
};
|
||||
</pre></div>
|
||||
|
||||
would be executed in PHP as,
|
||||
<p>
|
||||
would be executed in PHP as
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
Ko::threats();
|
||||
</pre></div>
|
||||
|
|
@ -1158,7 +1237,7 @@ should suffice in most cases:
|
|||
</div>
|
||||
|
||||
<p>
|
||||
If you only need to support SWIG >= 4.1.0, you can just use the
|
||||
If you only need to support SWIG >= 4.1.0, you can just use the
|
||||
<tt>($error != NULL)</tt> condition.
|
||||
</p>
|
||||
|
||||
|
|
|
|||
|
|
@ -281,12 +281,12 @@ You must use <a href="http://www.gnu.org/software/make/">GNU make</a> to build a
|
|||
</p>
|
||||
|
||||
<p>
|
||||
<a href="http://www.pcre.org/">PCRE</a>
|
||||
<a href="http://www.pcre.org/">PCRE2</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
|
||||
pcre2-config must be available. If you have PCRE2 headers and libraries but not
|
||||
pcre2-config itself or, alternatively, wish to override the compiler or linker
|
||||
flags returned by pcre2-config, you may set PCRE2_LIBS and PCRE2_CFLAGS variables
|
||||
to be used instead. And if you don't have PCRE2 at all, the configure script
|
||||
will provide instructions for obtaining it.
|
||||
</p>
|
||||
|
||||
|
|
|
|||
|
|
@ -1608,7 +1608,7 @@ public:
|
|||
</div>
|
||||
|
||||
<p>
|
||||
In Python, the static member can be access in three different ways:
|
||||
In Python, the static member can be accessed in three different ways:
|
||||
</p>
|
||||
|
||||
<div class="targetlang">
|
||||
|
|
@ -1616,7 +1616,7 @@ In Python, the static member can be access in three different ways:
|
|||
>>> example.Spam_foo() # Spam::foo()
|
||||
>>> s = example.Spam()
|
||||
>>> s.foo() # Spam::foo() via an instance
|
||||
>>> example.Spam.foo() # Spam::foo(). Python-2.2 only
|
||||
>>> example.Spam.foo() # Spam::foo() using Python-2.2 and later
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
|
|
@ -1627,16 +1627,31 @@ last technique is only available in Python-2.2 and later versions.
|
|||
|
||||
<p>
|
||||
Static member variables are currently accessed as global variables. This means,
|
||||
they are accessed through <tt>cvar</tt> like this:
|
||||
they are accessed through <tt>cvar</tt> or via an instance property:
|
||||
</p>
|
||||
|
||||
<div class="targetlang">
|
||||
<pre>
|
||||
>>> print example.cvar.Spam_bar
|
||||
>>> example.cvar.Spam_bar # Spam::bar
|
||||
7
|
||||
>>> s = example.Spam()
|
||||
>>> s.bar # Spam::bar via an instance property
|
||||
7
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
The <tt>-builtin</tt> option uses a metaclass to additionally provide access as follows:
|
||||
</p>
|
||||
|
||||
<div class="targetlang">
|
||||
<pre>
|
||||
>>> example.Spam.bar # Spam::bar using -builtin option only
|
||||
7
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
|
||||
<H3><a name="Python_nn21">33.3.8 C++ inheritance</a></H3>
|
||||
|
||||
|
||||
|
|
@ -4939,7 +4954,6 @@ object to be used as a <tt>char **</tt> object.
|
|||
if (PyString_Check(o)) {
|
||||
$1[i] = PyString_AsString(PyList_GetItem($input, i));
|
||||
} else {
|
||||
free($1);
|
||||
PyErr_SetString(PyExc_TypeError, "list must contain strings");
|
||||
SWIG_fail;
|
||||
}
|
||||
|
|
@ -5038,7 +5052,6 @@ previous example:
|
|||
if (PyString_Check(o)) {
|
||||
$2[i] = PyString_AsString(PyList_GetItem($input, i));
|
||||
} else {
|
||||
free($2);
|
||||
PyErr_SetString(PyExc_TypeError, "list must contain strings");
|
||||
SWIG_fail;
|
||||
}
|
||||
|
|
|
|||
|
|
@ -196,7 +196,7 @@ slices)
|
|||
<p>
|
||||
Wrapping of C++ classes for R works quite well. R has a special
|
||||
type, known as an external reference, that can be used as a pointer
|
||||
to arbitary things, including C++ classes. The proxy layers generated
|
||||
to arbitrary things, including C++ classes. The proxy layers generated
|
||||
for other classes are not required.
|
||||
</p>
|
||||
|
||||
|
|
@ -265,7 +265,7 @@ v2$Axles
|
|||
[1] 4
|
||||
v1$Available
|
||||
[1] FALSE
|
||||
# Set availabilty
|
||||
# Set availability
|
||||
v1$Available <- TRUE
|
||||
v1$Available
|
||||
[1] TRUE
|
||||
|
|
|
|||
|
|
@ -47,6 +47,7 @@
|
|||
<li><a href="#SWIG_rename_ignore">Renaming and ignoring declarations</a>
|
||||
<ul>
|
||||
<li><a href="#SWIG_nn29">Simple renaming of specific identifiers</a>
|
||||
<li><a href="#SWIG_ignore">Ignoring identifiers</a>
|
||||
<li><a href="#SWIG_advanced_renaming">Advanced renaming support</a>
|
||||
<li><a href="#SWIG_limiting_renaming">Limiting global renaming rules</a>
|
||||
<li><a href="#SWIG_chosen_unignore">Ignoring everything then wrapping a few selected symbols</a>
|
||||
|
|
@ -208,7 +209,7 @@ General Options
|
|||
-oh <headfile> - Set name of C++ output header file for directors to <headfile>
|
||||
-outcurrentdir - Set default output dir to current dir instead of input file's path
|
||||
-outdir <dir> - Set language specific files output directory to <dir>
|
||||
-pcreversion - Display PCRE version information
|
||||
-pcreversion - Display PCRE2 version information
|
||||
-small - Compile in virtual elimination and compact mode
|
||||
-swiglib - Report location of SWIG library and exit
|
||||
-templatereduce - Reduce all the typedefs in templates
|
||||
|
|
@ -1469,14 +1470,14 @@ SWIG generates the following code:
|
|||
<pre>
|
||||
/* C mode */
|
||||
void foo_set(char *value) {
|
||||
if (foo) free(foo);
|
||||
free(foo);
|
||||
foo = (char *) malloc(strlen(value)+1);
|
||||
strcpy(foo, value);
|
||||
}
|
||||
|
||||
/* C++ mode. When -c++ option is used */
|
||||
void foo_set(char *value) {
|
||||
if (foo) delete [] foo;
|
||||
delete [] foo;
|
||||
foo = new char[strlen(value)+1];
|
||||
strcpy(foo, value);
|
||||
}
|
||||
|
|
@ -1841,6 +1842,25 @@ all to `output' by specifying :</p>
|
|||
%rename(output) print; // Rename all `print' functions to `output'
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
A new <tt>%rename</tt> for the same name will replace the current
|
||||
<tt>%rename</tt> for all uses after it in the file, and setting the
|
||||
new name to "" will remove the rename. So, for instance, if you
|
||||
wanted to rename some things in one file and not in another, you could
|
||||
do:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%rename(print1) print;
|
||||
%include "header1.h" //Anything "print" in here will become "print1"
|
||||
%rename(print2) print;
|
||||
%include "header2.h" //Anything "print" in here will become "print2"
|
||||
%rename("") print;
|
||||
%include "header3.h" //Anything "print" in here will remain "print"
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
SWIG does not normally perform any checks to see if the functions it wraps are
|
||||
already defined in the target scripting language. However, if you are
|
||||
|
|
@ -1857,6 +1877,9 @@ If you are using the <tt>%rename</tt> directive and C++, make sure you read the
|
|||
for method overloading and default arguments.
|
||||
</p>
|
||||
|
||||
<H4><a name="SWIG_ignore">5.4.7.2 Ignoring identifiers</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
Closely related to <tt>%rename</tt> is the <tt>%ignore</tt> directive. <tt>%ignore</tt> instructs SWIG
|
||||
to ignore declarations that match a given identifier. For example:
|
||||
|
|
@ -1896,7 +1919,7 @@ This directive is still supported, but it is deprecated and should probably be a
|
|||
directive is more powerful and better supports wrapping of raw header file information.
|
||||
</p>
|
||||
|
||||
<H4><a name="SWIG_advanced_renaming">5.4.7.2 Advanced renaming support</a></H4>
|
||||
<H4><a name="SWIG_advanced_renaming">5.4.7.3 Advanced renaming support</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2022,8 +2045,8 @@ and a more descriptive one, but the two functions are otherwise equivalent:
|
|||
<td>String after (Perl-like) regex substitution operation. This function
|
||||
allows applying arbitrary regular expressions to the identifier names. The
|
||||
<i>pattern</i> part is a regular expression in Perl syntax (as supported
|
||||
by the <a href="http://www.pcre.org/">Perl Compatible Regular Expressions (PCRE)</a>)
|
||||
library and the <i>subst</i> string
|
||||
by the <a href="http://www.pcre.org/">Perl Compatible Regular Expressions</a>)
|
||||
(PCRE2 library) and the <i>subst</i> string
|
||||
can contain back-references of the form <tt>\N</tt> where <tt>N</tt> is a digit
|
||||
from 0 to 9, or one of the following escape sequences: <tt>\l</tt>, <tt>\L</tt>,
|
||||
<tt>\u</tt>, <tt>\U</tt> or <tt>\E</tt>. The back-references are replaced with the
|
||||
|
|
@ -2105,7 +2128,7 @@ are exactly equivalent and <tt>%rename</tt> can be used to selectively ignore
|
|||
multiple declarations using the previously described matching possibilities.
|
||||
</p>
|
||||
|
||||
<H4><a name="SWIG_limiting_renaming">5.4.7.3 Limiting global renaming rules</a></H4>
|
||||
<H4><a name="SWIG_limiting_renaming">5.4.7.4 Limiting global renaming rules</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2203,7 +2226,7 @@ wrap C++ overloaded functions and methods or C++ methods which use default argum
|
|||
</p>
|
||||
|
||||
|
||||
<H4><a name="SWIG_chosen_unignore">5.4.7.4 Ignoring everything then wrapping a few selected symbols</a></H4>
|
||||
<H4><a name="SWIG_chosen_unignore">5.4.7.5 Ignoring everything then wrapping a few selected symbols</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2227,6 +2250,23 @@ the following approach could be taken:
|
|||
%rename("%s") Star::shine; // named method
|
||||
|
||||
%include "myheader.h"
|
||||
|
||||
%rename("%s") ""; // Undo the %ignore
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
If <tt>Star</tt> was in the <tt>Galaxy</tt> namespace, you would need
|
||||
to unignore the namespace, too, and add the namespace to all the
|
||||
renames:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%rename("%s") Galaxy;
|
||||
%rename("%s") Galaxy::Star;
|
||||
%rename("%s") Galaxy::Star::Star;
|
||||
...
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
|
|
@ -2241,6 +2281,7 @@ members of the class, so when the chosen class is unignored, all of its methods
|
|||
%rename($ignore, %$isclass) ""; // Only ignore all classes
|
||||
%rename("%s") Star; // Unignore 'Star'
|
||||
%include "myheader.h"
|
||||
%rename("%s", %$isclass) ""; // Stop ignoring all classes
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
|
|
@ -2594,8 +2635,7 @@ char *Foo_name_get(Foo *obj) {
|
|||
}
|
||||
|
||||
char *Foo_name_set(Foo *obj, char *c) {
|
||||
if (obj->name)
|
||||
free(obj->name);
|
||||
free(obj->name);
|
||||
obj->name = (char *) malloc(strlen(c)+1);
|
||||
strcpy(obj->name, c);
|
||||
return obj->name;
|
||||
|
|
@ -2976,6 +3016,11 @@ typedef struct Vector {
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
You'll also need to use these names if you want to directly call methods added
|
||||
using <tt>%extend</tt> from other C/C++ code.
|
||||
</p>
|
||||
|
||||
<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:
|
||||
|
|
|
|||
|
|
@ -48,6 +48,9 @@
|
|||
</ul>
|
||||
<li><a href="#SWIGPlus_nn28">Overloaded operators</a>
|
||||
<li><a href="#SWIGPlus_class_extension">Class extension</a>
|
||||
<ul>
|
||||
<li><a href="#SWIGPlus_replacing_methods">Replacing class methods</a>
|
||||
</ul>
|
||||
<li><a href="#SWIGPlus_nn30">Templates</a>
|
||||
<ul>
|
||||
<li><a href="#SWIGPlus_template_directive">The %template directive</a>
|
||||
|
|
@ -2944,6 +2947,59 @@ be used to extend a structure with more than just methods, a more suitable
|
|||
directive name has been chosen.
|
||||
</p>
|
||||
|
||||
<H3><a name="SWIGPlus_replacing_methods">6.17.1 Replacing class methods</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
Suppose there is a method in a class that you need to replace and keep the method name the same.
|
||||
This can be achieved combining the <tt>%extend</tt> and <tt>%ignore</tt> directives covered earlier.
|
||||
Here is an example to replace the <tt>MyClass::mymethod()</tt>:
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%extend MyClass {
|
||||
void mymethod() {
|
||||
std::cout << "swig mymethod" << std::endl;
|
||||
}
|
||||
}
|
||||
|
||||
%ignore MyClass::mymethod;
|
||||
|
||||
%inline %{
|
||||
class MyClass {
|
||||
public:
|
||||
void mymethod() {
|
||||
std::cout << "class mymethod" << std::endl;
|
||||
}
|
||||
};
|
||||
%}
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Or if your code organization makes more sense to put
|
||||
the <tt>%extend</tt> after the class definition, you would need the following:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
<pre>
|
||||
%rename("") MyClass::mymethod; // unignores the method
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
before the <tt>%extend</tt> or SWIG will continue to ignore
|
||||
<tt>mymethod()</tt>, even in an <tt>%extend</tt>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Note that you can call the class method from the method
|
||||
in <tt>%extend</tt>, just use <tt>self->mymethod()</tt> and it will call
|
||||
the class method, not the one in <tt>%extend</tt>.
|
||||
</p>
|
||||
|
||||
|
||||
|
||||
<H2><a name="SWIGPlus_nn30">6.18 Templates</a></H2>
|
||||
|
||||
|
||||
|
|
@ -3632,7 +3688,7 @@ Alternatively, you could expand the constructor template in selected instantiati
|
|||
|
||||
// Create default and conversion constructors
|
||||
%extend pair<double, double> {
|
||||
%template(paird) pair<double, dobule>; // Default constructor
|
||||
%template(paird) pair<double, double>; // Default constructor
|
||||
%template(pairc) pair<int, int>; // Conversion constructor
|
||||
};
|
||||
</pre>
|
||||
|
|
@ -3647,7 +3703,7 @@ instead:
|
|||
<pre>
|
||||
// Create default and conversion constructors
|
||||
%extend pair<double, double> {
|
||||
%template(pair) pair<double, dobule>; // Default constructor
|
||||
%template(pair) pair<double, double>; // Default constructor
|
||||
%template(pair) pair<int, int>; // Conversion constructor
|
||||
};
|
||||
</pre>
|
||||
|
|
|
|||
|
|
@ -1227,7 +1227,15 @@ _108fea88_p_Bar
|
|||
|
||||
<p>
|
||||
Finally, to destroy objects created from Tcl, you can either let the object
|
||||
name go out of scope or you can explicitly delete the object. For example:
|
||||
name go out of scope or you can explicitly delete the object as shown below.
|
||||
Objects won't get automatically destroyed when the Tcl program exits, so if
|
||||
it's important that the C++ destructor is called for a class you'll need to
|
||||
make sure that you explicitly do this for objects of that class before program
|
||||
exit.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
For example:
|
||||
</p>
|
||||
|
||||
<div class="code">
|
||||
|
|
@ -2811,9 +2819,7 @@ used as a <tt>char **</tt> object.
|
|||
|
||||
// This gives SWIG some cleanup code that will get called after the function call
|
||||
%typemap(freearg) char ** {
|
||||
if ($1) {
|
||||
free($1);
|
||||
}
|
||||
free($1);
|
||||
}
|
||||
|
||||
// Now a test functions
|
||||
|
|
|
|||
|
|
@ -3103,7 +3103,7 @@ as shown. To work with heap allocated data, the following technique can be use
|
|||
}
|
||||
}
|
||||
%typemap(freearg) float value[ANY] {
|
||||
if ($1) free($1);
|
||||
free($1);
|
||||
}
|
||||
</pre>
|
||||
</div>
|
||||
|
|
@ -3556,7 +3556,7 @@ maps perform the conversion described for the above example:
|
|||
}
|
||||
|
||||
%typemap(freearg) (int argc, char *argv[]) {
|
||||
if ($2) free($2);
|
||||
free($2);
|
||||
}
|
||||
|
||||
/* Required for C++ method overloading */
|
||||
|
|
|
|||
|
|
@ -428,6 +428,7 @@ example.i(4) : Syntax error in input(1).
|
|||
<li>324. Named nested template instantiations not supported. Processing as if no name was given to %template().
|
||||
<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>327. Extern template ignored.
|
||||
<li>350. operator new ignored.
|
||||
<li>351. operator delete ignored.
|
||||
<li>352. operator+ ignored.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
||||
<html>
|
||||
<head>
|
||||
<title>Getting started on Windows</title>
|
||||
|
|
@ -29,17 +29,16 @@
|
|||
</ul>
|
||||
<li><a href="#Windows_other_compilers">Instructions for using the Examples with other compilers</a>
|
||||
</ul>
|
||||
<li><a href="#Windows_cygwin_mingw">SWIG on Cygwin and MinGW</a>
|
||||
<ul>
|
||||
<li><a href="#Windows_swig_exe">Building swig.exe on Windows</a>
|
||||
<ul>
|
||||
<li><a href="#Windows_cmake">Building swig.exe using CMake</a>
|
||||
<li><a href="#Windows_mingw_msys">Building swig.exe using MSYS2</a>
|
||||
<li><a href="#Windows_msys2">Building swig.exe using MSYS2</a>
|
||||
<li><a href="#Windows_mingw_msys">Building swig.exe using MinGW and MSYS</a>
|
||||
<li><a href="#Windows_cygwin">Building swig.exe using Cygwin</a>
|
||||
</ul>
|
||||
<ul>
|
||||
<li><a href="#Windows_examples_cygwin">Running the examples on Windows using Cygwin</a>
|
||||
</ul>
|
||||
</ul>
|
||||
<li><a href="#Windows_interface_file">Microsoft extensions and other Windows quirks</a>
|
||||
</ul>
|
||||
</div>
|
||||
|
|
@ -210,94 +209,97 @@ RUBY_LIB: D:\ruby\lib\mswin32-ruby16.lib<br>
|
|||
If you do not have access to Visual C++ you will have to set up project files / Makefiles for your chosen compiler. There is a section in each of the language modules detailing what needs setting up using Visual C++ which may be of some guidance. Alternatively you may want to use Cygwin as described in the following section.
|
||||
</p>
|
||||
|
||||
<H2><a name="Windows_cygwin_mingw">3.3 SWIG on Cygwin and MinGW</a></H2>
|
||||
<H2><a name="Windows_swig_exe">3.3 Building swig.exe on Windows</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
SWIG can also be compiled and run using <a href="http://www.cygwin.com">Cygwin</a> or <a href="http://www.mingw.org">MinGW</a> which provides a Unix like front end to Windows and comes free with gcc, an ISO C/C++ compiler. However, this is not a recommended approach as the prebuilt executable is supplied.
|
||||
The SWIG distribution provides a pre-built swig.exe and so it is not necessary for users to build the SWIG executable.
|
||||
However, this section is provided for those that want to modify the SWIG source code in a Windows environment.
|
||||
Normally this is not needed, so most people will want to ignore this section.
|
||||
</p>
|
||||
|
||||
<H3><a name="Windows_swig_exe">3.3.1 Building swig.exe on Windows</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
If you want to replicate the build of swig.exe that comes with the download, follow the MinGW instructions below.
|
||||
This is not necessary to use the supplied swig.exe.
|
||||
This information is provided for those that want to modify the SWIG source code in a Windows environment.
|
||||
Normally this is not needed, so most people will want to ignore this section.
|
||||
There are various ways to build the SWIG executable including <a href="https://cmake.org/">CMake</a> which is able to generate project files for building with Visual Studio.
|
||||
SWIG can also be compiled and run using <a href="https://www.msys2.org/">MSYS2</a>, <a href="http://www.cygwin.com">Cygwin</a> or <a href="http://www.mingw.org">MinGW</a>, all of which provide a Unix like front end to Windows and comes free with the gcc C/C++ compiler.
|
||||
</p>
|
||||
|
||||
<H4><a name="Windows_cmake">3.3.1.1 Building swig.exe using CMake</a></H4>
|
||||
|
||||
<H3><a name="Windows_cmake">3.3.1 Building swig.exe using CMake</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
SWIG can also be built using <a href="https://cmake.org/">CMake</a> and Visual Studio rather than autotools. As with the other approaches to
|
||||
SWIG can be built using <a href="https://cmake.org/">CMake</a> and Visual Studio rather than autotools. As with the other approaches to
|
||||
building SWIG the dependencies need to be installed. The steps below are one of a number of ways of installing the dependencies without requiring Cygwin or MinGW.
|
||||
For fully working build steps always check the Continuous Integration setups currently detailed in the <a href="https://github.com/swig/swig/blob/master/appveyor.yml">Appveyor YAML file</a>.
|
||||
For fully working build steps always check the Continuous Integration (CI) setups currently detailed in the <a href="https://github.com/swig/swig/blob/master/appveyor.yml">Appveyor YAML file</a>.
|
||||
</p>
|
||||
|
||||
<ol>
|
||||
<li>
|
||||
Install Nuget from <a href="https://www.nuget.org/downloads">https://www.nuget.org/downloads</a> (v5.8.1 is used in this example, and installed to C:\Tools). Nuget is the package manager
|
||||
for .NET, but allows us to easily install <a href="https://www.pcre.org/">PCRE</a> and other dependencies required by SWIG.
|
||||
Install Nuget from <a href="https://www.nuget.org/downloads">https://www.nuget.org/downloads</a> (v6.0.0 is used in this example, and installed to <tt>C:\Tools</tt>). Nuget is the package manager
|
||||
for .NET, but allows us to easily install <a href="https://cmake.org/">CMake</a> and other dependencies required by SWIG.
|
||||
</li>
|
||||
<li>
|
||||
Install CMake using the following command: <pre>C:\Tools\nuget install CMake-win64 -Version 3.15.5 -OutputDirectory C:\Tools\CMake</pre>
|
||||
Install <a href="https://www.nuget.org/packages/CMake-win64/">CMake-win64 Nuget package</a> using the following command: <pre>C:\Tools\nuget install CMake-win64 -Version 3.15.5 -OutputDirectory C:\Tools\CMake</pre>
|
||||
Alternatively you can download CMake from <a href="https://cmake.org/download/">https://cmake.org/download/</a>.
|
||||
</li>
|
||||
<li>
|
||||
Install Bison using the following command: <pre>C:\Tools\nuget install bison-win32 -Version 2.4.1.1 -OutputDirectory C:\Tools\bison</pre>
|
||||
Alternatively download Bison from <a href="https://sourceforge.net/projects/gnuwin32/files/bison/">https://sourceforge.net/projects/gnuwin32/files/bison/</a> (2.4.1 is used in this example)
|
||||
and save to a folder e.g. C:\Tools\Bison
|
||||
Install the <a href="https://www.nuget.org/packages/bison/">Bison Nuget package</a> using the following command: <pre>C:\Tools\nuget install Bison -Version 3.7.4 -OutputDirectory C:\Tools\bison</pre>
|
||||
Alternatively download Bison from <a href="https://sourceforge.net/projects/winflexbison/files/">https://sourceforge.net/projects/winflexbison/files/</a> (Bison 3.7.4 is used in this example)
|
||||
and save to a folder e.g. <tt>C:\Tools\Bison</tt>
|
||||
</li>
|
||||
<li>
|
||||
Install PCRE using Nuget using the following command: <pre>C:\Tools\nuget install pcre -Version 8.33.0.1 -OutputDirectory C:\Tools\pcre</pre>
|
||||
Unfortunately, PCRE2 is not yet available on Nuget. Instead we will use CMake to build and install <a href="https://www.pcre.org/">PCRE2</a> to <tt>C:\Tools\pcre2</tt> using the following commands:
|
||||
<div class="shell"><pre>
|
||||
cd C:\
|
||||
SET PATH=C:\Tools\CMake\CMake-win64.3.15.5\bin;%PATH%
|
||||
git clone https://github.com/PhilipHazel/pcre2.git
|
||||
cd pcre2
|
||||
cmake -G "Visual Studio 16 2019" -A x64 -DCMAKE_INSTALL_PREFIX=C:/Tools/pcre2 -S . -B build
|
||||
cmake --build build --config Release --target install
|
||||
</pre></div>
|
||||
Alternatively, set <tt>WITH_PCRE=OFF</tt> to disable PCRE2 support if you are sure you do not require it.
|
||||
</li>
|
||||
<li>
|
||||
We will also need the SWIG source code. Either download a zipped archive from GitHub, or if git is installed clone the latest codebase
|
||||
using <pre>git clone https://github.com/swig/swig.git</pre>
|
||||
In this example we are assuming the source code is available at C:\swig
|
||||
In this example we are assuming the source code is available at <tt>C:\swig</tt>
|
||||
</li>
|
||||
</ol>
|
||||
|
||||
<p>
|
||||
We are assuming Visual Studio 2017 is installed. For other versions of Visual Studio change <i>"Visual Studio 15 2017 Win64"</i> to the relevant
|
||||
<a href="https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html#visual-studio-generators">Visual Studio Generator</a>.
|
||||
Now we have all the required dependencies we can build SWIG using the commands below. We add the required build tools to the system PATH, and then
|
||||
build a Release version of SWIG. If all runs successfully a new swig.exe should be generated in a /Release folder.
|
||||
</p>
|
||||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
<li>
|
||||
<p>
|
||||
Now we have all the required dependencies we can build SWIG using the commands below. We are assuming Visual Studio 2019 is installed. For other versions of Visual Studio change <tt>"Visual Studio 16 2019 -A x64"</tt> to the relevant
|
||||
<a href="https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html#visual-studio-generators">Visual Studio Generator</a> and
|
||||
architecture. We add the required build tools to the system PATH, and then
|
||||
build a Release version of SWIG. If all runs successfully a new swig.exe should be generated in the <tt>C:/swig/install2/bin</tt> folder.
|
||||
</p>
|
||||
<div class="shell"> <pre>
|
||||
cd C:\swig
|
||||
SET PATH=C:\Tools\CMake\CMake-win64.3.15.5\bin;C:\Tools\bison\bison-win32.2.4.1.1\tools\native\bin;%PATH%
|
||||
SET PCRE_ROOT=C:\Tools\pcre\pcre.8.33.0.1\build\native
|
||||
SET PATH=C:\Tools\CMake\CMake-win64.3.15.5\bin;C:\Tools\bison\Bison.3.7.4\bin;%PATH%
|
||||
SET PCRE_ROOT=C:/Tools/pcre2
|
||||
SET PCRE_PLATFORM=x64
|
||||
cmake -G "Visual Studio 15 2017 Win64" -DCMAKE_INSTALL_PREFIX="%CD:\=/%/install2" -DCMAKE_C_FLAGS="/DPCRE_STATIC" ^
|
||||
-DPCRE_INCLUDE_DIR=%PCRE_ROOT%/include -DPCRE_LIBRARY=%PCRE_ROOT%/lib/v110/%PCRE_PLATFORM%/Release/static/utf8/pcre8.lib .
|
||||
cmake --build . --config Release
|
||||
cmake -G "Visual Studio 16 2019" -A x64 -DCMAKE_INSTALL_PREFIX="%CD:\=/%/install2" -DCMAKE_C_FLAGS="/DPCRE2_STATIC" ^
|
||||
-DCMAKE_CXX_FLAGS="/DPCRE2_STATIC" -DPCRE2_INCLUDE_DIR=%PCRE_ROOT%/include -DPCRE2_LIBRARY=%PCRE_ROOT%/lib/pcre2-8-static.lib -S . -B build
|
||||
cmake --build build --config Release --target install
|
||||
|
||||
REM to test the exe
|
||||
cd /Release
|
||||
cd install2/bin
|
||||
swig.exe -help
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
</pre></div>
|
||||
</li>
|
||||
</ol>
|
||||
<p>
|
||||
In addition to Release builds you can create a Debug build using:
|
||||
</p>
|
||||
<div class="shell">
|
||||
<pre>cmake --build . --config Debug</pre>
|
||||
<pre>cmake --build build --config Debug</pre>
|
||||
</div>
|
||||
<p>
|
||||
A Visual Studio solution file should be generated named swig.sln. This can be opened and debugged by running the swig project and setting the
|
||||
Debugging Command Arguments. For example to debug one of the test-suite .i files included with the SWIG source use the following:
|
||||
A Visual Studio solution file should be generated named swig.sln. This can be opened and debugged by running the swig project and setting <tt>Properties > Debugging > Command Arguments</tt>. For example to debug one of the test-suite .i files included with the SWIG source use the following:
|
||||
</p>
|
||||
<div class="shell">
|
||||
<pre>-python -c++ -o C:\Temp\doxygen_parsing.cpp C:\swig\Examples\test-suite\doxygen_parsing.i</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Windows_mingw_msys">3.3.1.2 Building swig.exe using MSYS2</a></H4>
|
||||
<H3><a name="Windows_msys2">3.3.2 Building swig.exe using MSYS2</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -310,7 +312,7 @@ Install the packages needed to build swig:<br>
|
|||
|
||||
<div class="shell">
|
||||
<pre>
|
||||
pacman -S git autoconf automake bison gcc make pcre-devel
|
||||
pacman -S git autoconf automake bison gcc make pcre2-devel
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
|
|
@ -349,7 +351,7 @@ make install
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Windows_mingw_msys">3.3.1.3 Building swig.exe using MinGW and MSYS</a></H4>
|
||||
<H3><a name="Windows_mingw_msys">3.3.3 Building swig.exe using MinGW and MSYS</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -444,10 +446,10 @@ the autotools will fail miserably on those.
|
|||
</li>
|
||||
|
||||
<li>
|
||||
The PCRE third party library needs to be built next.
|
||||
Download the latest PCRE source tarball, such as <tt>pcre-8.10.tar.bz2</tt>, from
|
||||
<a href=http://www.pcre.org>PCRE</a> and place in the <tt>/usr/src/swig</tt> directory.
|
||||
Build PCRE as a static library using the Tools/pcre-build.sh script as follows:
|
||||
The PCRE2 third party library needs to be built next.
|
||||
Download the latest PCRE2 source tarball, such as <tt>pcre2-10.39.tar.bz2</tt>, from
|
||||
<a href=http://www.pcre.org>www.pcre.org</a> and place in the <tt>/usr/src/swig</tt> directory.
|
||||
Build PCRE2 as a static library using the Tools/pcre-build.sh script as follows:
|
||||
|
||||
<div class="shell"><pre>
|
||||
cd /usr/src/swig
|
||||
|
|
@ -467,7 +469,7 @@ make
|
|||
</ol>
|
||||
|
||||
|
||||
<H4><a name="Windows_cygwin">3.3.1.4 Building swig.exe using Cygwin</a></H4>
|
||||
<H3><a name="Windows_cygwin">3.3.4 Building swig.exe using Cygwin</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -479,7 +481,7 @@ These files are generated using the <tt>autogen.sh</tt> script and will only nee
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Windows_examples_cygwin">3.3.2 Running the examples on Windows using Cygwin</a></H3>
|
||||
<H4><a name="Windows_examples_cygwin">3.3.4.1 Running the examples on Windows using Cygwin</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue