diff --git a/Doc/Manual/Contents.html b/Doc/Manual/Contents.html index c135b7c6f..e997e46cb 100644 --- a/Doc/Manual/Contents.html +++ b/Doc/Manual/Contents.html @@ -488,6 +488,7 @@
+Each invocation of SWIG requires a module name to be specified. +The module name is used to name the resulting target language extension module. +Exactly what this means and and what the name is used for +depends on the target language, for example the name can define +a target language namespace or merely be a useful name for naming files or helper classes. +
+ ++The module name can be supplied in one of two ways. +The first is to specify it with the special %module +directive. This directive must appear at the beginning of the interface file. +The general form of this directive is: +
+ ++%module(option1="value1",option2="value2",...) modulename +
+where the modulename is mandatory and the options add one or more optional additional features. +Typically no options are specified, for example: +
+ ++%module mymodule +
+The second way to specify the module name is with the -module command line option, for example -module mymodule. +If the module name is supplied on the command line, it overrides the name specified by the +%module directive. +
+When first working with SWIG, users commonly start by creating a single module. That is, you might define a single SWIG interface that wraps some set of C/C++ code. You then compile all of the generated -wrapper code into a module and use it. For large applications, however, +wrapper code together and use it. For large applications, however, this approach is problematic---the size of the generated wrapper code can be rather large. Moreover, it is probably easier to manage the target language interface when it is broken up into smaller pieces. @@ -34,10 +72,11 @@ target language interface when it is broken up into smaller pieces.
This chapter describes the problem of using SWIG in programs -where you want to create a collection of modules. +where you want to create a collection of modules. +Each module in the collection is created via separate invocations of SWIG.
-@@ -135,7 +174,7 @@ in parallel from multiple threads as SWIG provides no locking - for more on that issue, read on.
-@@ -201,7 +240,7 @@ can peacefully coexist. So the type structures are separated by the is empty. Only modules compiled with the same pair will share type information.
-As described in The run-time type checker, @@ -238,7 +277,7 @@ SWIG_TYPE_TABLE to be the same as the module whose types you are trying to access.
-@@ -249,7 +288,7 @@ into it. This is very often NOT what you want and it can lead to unexpect behavior. When working with dynamically loadable modules, you should try to work exclusively with shared libraries.
-@@ -257,7 +296,7 @@ Due to the complexity of working with shared libraries and multiple modules, it an outside reference. John Levine's "Linkers and Loaders" is highly recommended.
-diff --git a/Doc/Manual/SWIG.html b/Doc/Manual/SWIG.html index 3cbd3cf21..1bdc6b4d0 100644 --- a/Doc/Manual/SWIG.html +++ b/Doc/Manual/SWIG.html @@ -174,15 +174,8 @@ int bar(int x); ...
-The name of the module is supplied using the special %module -directive (or the -module command line option). This -directive must appear at the beginning of the file and is used to name -the resulting target language extension module. Exactly what this results -in depends on the target language, eg the module name can define -a target language namespace or merely be a useful name for naming files or helper classes. -If the module name is supplied on the -command line, it overrides the name specified with the -%module directive. +The module name is supplied using the special %module +directive. Modules are described further in the Modules Introduction section.
@@ -2889,12 +2882,12 @@ source/header file.