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

1.3.22 update

Browse source 
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk/SWIG@6179 626c5289-ae23-0410-ae9c-e8d60b6d4f22
This commit is contained in:
William S Fulton 2004-08-30 21:40:55 +00:00
commit 4882c81236
6 changed files with 88 additions and 207 deletions
Download patch file Download diff file Expand all files Collapse all files

38
ANNOUNCE
View file

@ -1,11 +1,11 @@
*** ANNOUNCE: SWIG 1.3.20 ***
*** ANNOUNCE: SWIG 1.3.22 ***
http://www.swig.org
December 17, 2003
September 1, 2004
We're pleased to announce SWIG 1.3.20, the latest installment in the
SWIG development effort. SWIG-1.3.20 includes a number of bug fixes
We're pleased to announce SWIG-1.3.22, the latest installment in the
SWIG development effort. SWIG-1.3.22 includes a number of bug fixes
and large number of enhancements throughout.
What is SWIG?
@ -22,15 +22,15 @@ Availability:
-------------
The release is available for download on Sourceforge at
http://prdownloads.sourceforge.net/swig/swig-1.3.20.tar.gz
http://prdownloads.sourceforge.net/swig/swig-1.3.22.tar.gz
Within the next day, a Windows version will also be made available at
http://prdownloads.sourceforge.net/swig/swigwin-1.3.20.zip
http://prdownloads.sourceforge.net/swig/swigwin-1.3.22.zip
Release numbers
---------------
With SWIG1.3, we are adopting an odd/even version numbering scheme for
With SWIG-1.3, we are adopting an odd/even version numbering scheme for
SWIG. Odd version numbers (1.3, 1.5, 1.7, etc...) are considered to
be development releases. Even numbers (1.4,1.6,1.8) are stable
releases. The current 1.3 effort is working to produce a stable 2.0
@ -40,14 +40,14 @@ continue to make periodic 1.3.x releases.
We need your help!
------------------
Even if you are perfectly happy with SWIG1.1, we can still use your
Even if you are perfectly happy with SWIG-1.1, we can still use your
feedback. First, we like to know about compilation problems and other
issues concerning the building of SWIG. Second, if SWIG1.3 is unable
issues concerning the building of SWIG. Second, if SWIG-1.3 is unable
to compile your old interface files, we would like to get information
about the features you are using. This information will help us find
bugs in the SWIG1.3 release, develop techniques for supporting
bugs in the SWIG-1.3 release, develop techniques for supporting
backwards compatibility, and write documentation that addresses
specific issues related to migrating from SWIG1.1 to SWIG1.3.
specific issues related to migrating from SWIG-1.1 to SWIG-1.3.
We are also looking for volunteers who would like to work on various
aspects of SWIG development. SWIG is an unfunded project that would
@ -55,21 +55,11 @@ not exist without volunteers. We are also looking for the developers
of other SWIG language modules. If you have developed a SWIG module
and would like to see it incorporated into the new release, please
contact us to obtain SWIG-CVS access. We are also more than willing
to help port your module from SWIG1.1 to SWIG1.3. Please send email
to help port your module from SWIG-1.1 to SWIG-1.3. Please send email
to beazley@cs.uchicago.edu for further information.
Please report problems with this release to swig-dev@cs.uchicago.edu.
Please report problems with this release to the swig-dev mailing list,
details at http://www.swig.org/mail.html.
--- The SWIG Developers

2
CHANGES
View file

@ -1,5 +1,7 @@
SWIG (Simplified Wrapper and Interface Generator)
See CHANGES.current for current version.
Version 1.3.21 (January 11, 2004)
==================================
01/10/2004: cheetah (William Fulton)

2
CHANGES.current
View file

@ -1,4 +1,4 @@
Version 1.3.22 (in progress)
Version 1.3.22 (September 1, 2004)
==================================
08/26/2004: wsfulton

2
FUTURE
View file

@ -320,7 +320,7 @@ we need your help.
not as bad as one might imagine.
- We are always looking for developers. Subscribe to
swig-dev@cs.uchicago.edu (http://mailman.cs.uchicago.edu/listinfo/swig-dev)
the swig-dev mailing list, details at http://www.swig.org/mail.html,
or send me email to get involved.
Acknowledgements

104
README
View file

@ -1,8 +1,6 @@
SWIG (Simplified Wrapper and Interface Generator)
Version: 1.3.21 (January 11, 2004)
$Header$
Version: 1.3.22 (September 1, 2004)
Tagline: SWIG is a compiler that integrates C and C++ with
languages including Perl, Python, Tcl, Guile, Mzscheme,
@ -63,7 +61,7 @@ Information about SWIG is also available in Japanese translation at
!!!!!!! IMPORTANT !!!!!!!
!!!!!!! !!!!!!!
!!!!!!! Previous SWIG users should read the documentation !!!!!!!
!!!!!!! file Doc/Manual/SWIG.html before trying to use SWIG1.3 !!!!!!!
!!!!!!! file Doc/Manual/SWIG.html before trying to use SWIG-1.3!!!!!!!
!!!!!!! on existing SWIG interfaces. This is the most current !!!!!!!
!!!!!!! documentation that describes new 1.3 features and !!!!!!!
!!!!!!! incompatibilities. !!!!!!!
@ -72,8 +70,30 @@ Information about SWIG is also available in Japanese translation at
What's New?
===========
SWIG-1.3.x offers a huge number of improvements over older SWIG-1.1 releases.
These improvements include:
SWIG-1.3.22 summary:
- Improved exception handling and translation of C errors or C++
exceptions into target language exceptions.
- Improved enum support, mapping to built-in Java 1.5 enums and C#
enums or the typesafe enum pattern for these two languages.
- Python - much better STL suppport and support for std::wstring,
wchar_t and FILE *.
- SWIG also supports Allegro CL now.
- 64 bit TCL support.
- Java and C#'s proxy classes are now nearly 100% generated from
typemaps and/or features for finer control on the generated code.
- SWIG runtime library support deprecation.
- Improved documentation. SWIG now additionally provides documentation
in the form of a single HTML page as well as a pdf document.
- Enhanced C++ friend declaration support.
- Better support for reference counted classes.
- Various %fragment improvements.
- RPM fixes.
- Various minor improvements and bug fixes for C#, Chicken, Guile, Java,
MzScheme, Perl, Php, Ruby and XML.
The SWIG-1.3.x development releases offer a huge number of improvements
over older SWIG-1.1 releases. These improvements include:
- Support for C++ overloaded functions and methods.
- Support for C++ smart pointers.
@ -98,7 +118,7 @@ These improvements include:
If you used SWIG-1.1, a number of old features are missing from SWIG-1.3.
- The SWIG1.1 documentation system is gone and hasn't been
- The SWIG-1.1 documentation system is gone and hasn't been
replaced yet. This is on the long-term to-do list.
- The Tcl7.x and Perl4 modules are deprecated and no longer
@ -115,24 +135,33 @@ If you used SWIG-1.1, a number of old features are missing from SWIG-1.3.
when it will return.
Although we are making some attempt to preserve backwards
compatibility with interfaces written for SWIG1.1, SWIG1.3
compatibility with interfaces written for SWIG-1.1, SWIG-1.3
incorporates a number of very substantial modifications to type
handling, typemaps, and wrapper code generation. Therefore, if you
are making extensive use of advanced SWIG features, interfaces written
for SWIG1.1 may not work. We apologize for the inconvenience, but
for SWIG-1.1 may not work. We apologize for the inconvenience, but
these changes are needed in order to fix a number of annoying
"features" in SWIG1.1. Hopefully the list of new features will
"features" in SWIG-1.1. Hopefully the list of new features will
provide enough incentive for you to upgrade (and that the
modifications to your interfaces will only be minor).
In addition, SWIG1.3 makes no attempt to be compatible with SWIG1.1 at
the C++ API level so language modules written for SWIG1.1 will most
In addition, SWIG-1.3 makes no attempt to be compatible with SWIG-1.1 at
the C++ API level so language modules written for SWIG-1.1 will most
definitely not work with this release.
See the documentation for details of the SWIG_VERSION preprocessor
symbol if you have backward compatibility issues and need to use more
than one version of SWIG.
The files NEW and CHANGES describe in some detail all of the important
changes that have been made to the system. Experienced users would be
well advised to read this.
Release Notes
=============
Please see the CHANGES files for a detailed list of bug fixes and
new features. The ANNOUNCE file has a summary of the changes.
Windows Installation
====================
Please see the Doc/Manual/Windows.html file for instructions on installing
@ -169,26 +198,18 @@ The file INSTALL details more about using configure. Also try
% ./configure --help.
The configure script will attempt to locate various packages on your
machine, including Tcl, Perl5, Python and other target languages that SWIG
The configure script will attempt to locate various packages on your machine
including Tcl, Perl5, Python and all the other target languages that SWIG
uses. 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.
SWIG includes an optional set of runtime libraries that are sometimes used
when working with multiple modules. By default, these aren't built due to
the wide variety of target languages, compilers, compiler flags, and other
configuration information that impacts the way that they have to be built.
However, if you want to build the runtime libraries in their "default"
configuration, type this:
% make -k runtime
% make install-runtime
The libraries aren't needed to use SWIG or to run most of the
examples. Therefore, you may want to skip this step until you've read
the documentation located in Doc/Manual/Modules.html.
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 documentation, Doc/Manual/Modules.html. The CHANGES file also lists some
examples which build the runtime library.
Notes:
@ -258,17 +279,13 @@ 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".
The Examples directory now includes Visual C++ project (.dsp) files for
building some of the examples on Windows (new in SWIG1.3.7).
The Examples directory also includes Visual C++ project (.dsp) files for
building some of the examples on Windows.
Known Issues
============
The SWIG-1.3.15 release includes a number of substantial changes to existing
language modules. These changes include modifications to the build environment
and the wrapper code itself. Certain examples may not compile or may need
minor changes to work.
Please see the CHANGES file for a detailed list of changes.
There are minor bugs, details of which are in the bug tracker, see
http://www.swig.org/bugs.html.
Troubleshooting
===============
@ -305,12 +322,16 @@ http://www.signal6.com/cgi-bin/wiki.pl.
Documentation
=============
The Doc/Manual directory contains the most recent set of updated
documentation for this release. As this is a development release, the
documentation is not entirely up to date and is being worked on. We
are working on it, but there is a lot of old documentation and it is going
to take time to complete. Please be patient or volunteer to help.
documentation for this release. The documentation is available in
a single page html format, multiple page html format or pdf format,
see Doc/Manual/index.html.
!! The most up-to-date information concerning new features in SWIG1.3 is the
This is a development release and the documentation is largely, but
not entirely up to date. We are working on it, but there
was a lot of old documentation and it is taking some time to
update and complete. Please be patient or volunteer to help.
!! The most up-to-date information concerning new features in SWIG-1.3 is the
!! file Doc/Manual/SWIG.html.
There is some technical developer documentation available in the
@ -324,7 +345,8 @@ have access to a limited variety of hardware (Linux, Solaris, OS-X,
and Windows). All contributions help.
If you would like to join the SWIG development team or contribute a
language module to the distribution, please contact swig-dev@cs.uchicago.edu.
language module to the distribution, please contact the swig-dev
mailing list, details at http://www.swig.org/mail.html.
-- The SWIG Maintainers

147
TODO
View file

@ -1,6 +1,6 @@
SWIG TO-DO
Release: SWIG-1.3.20
Release: SWIG-1.3.22
$Header$
-----------------------------------------------------------------------------
@ -31,36 +31,7 @@ defer ready to go. The primary obstacle lies in the target language
**** Typemap environments. Stay tuned.
[DONE] Merge "in" and "ignore" typemaps into a single "in" typemap.
This would solve a variety of subtle problems with multiple
argument typemaps and other typemap code. I propose to merge
the typemaps by making "ignore" a typemap attribute.
For example:
%typemap(in,ignore="1") int *OUTPUT (int temp) {
$1 = &temp;
}
This merging makes a lot of sense because "in" and "ignore"
typemaps both deal with input argument handling and they are
meant to be mutually exclusive of each other. By unifying
into a single typemap, you fix the mutual exclusion problem
(since there is only one typemap). I also think it makes
more sense to think of an "ignored" argument as a input value
property.
Update: Matthias proposes a generalization in which the
number of input arguments could be specified. For example:
%typemap(in,numinputs="0") int *OUTPUT (int temp) {
$1 = &temp;
}
This seems to be a better solution.
**** Implement "throws" typemaps for all of the target languages.
Partly implemented for Tcl, Perl, Python, Ruby, Java.
[DONE] Implement "throws" typemaps for all of the target languages.
*** "Nested" typemaps. The basic idea is similar to allowing one to
use $descriptor(T) for any T, rather than just $descriptor
@ -167,38 +138,6 @@ defer ready to go. The primary obstacle lies in the target language
[ Partially finished for Tcl/Python. ]
[DONE] Modify smart pointer handling to properly handle inheritance. For
example:
%ignore Foo;
class Foo {
public:
Blah *operator->();
};
class Bar : public Foo {
}
Bar should still allow access to Blah * through operator->().
[DONE] Virtual function optimization. If you have two classes like this:
class Foo {
public:
virtual int blah(int);
};
class Bar : public Foo {
public:
virtual int blah(int);
};
Then SWIG ought to be able to reuse the wrapper for Foo::blah as
Bar::blah. This should result in much smaller extension modules.
This feature is now enabled using the -fvirtual option.
** Restoration of the documentation system.
** Restoration of Objective-C support.
@ -223,9 +162,6 @@ Build
**** Make sure there are tests for *ALL* library files in the test-suite.
A number of files appear to be broken in SWIG-1.3.13.
[DONE] Move the Source/Modules1.1 directory into the Source/Modules directory
and deprecate Modules1.1.
Library
-------
@ -237,9 +173,6 @@ Library
Windows
-------
[DONE] Visual C++ Project files / Makefiles for building the runtime libraries.
Will require libtool mods to work under Cygwin.
All language modules
--------------------
@ -272,68 +205,11 @@ Ruby
acquire() methods to change this ownership status. Need to
address this for Ruby as well.
[DONE] Investigate the new object allocation framework that has been
implemented for Ruby 1.8 and determine what (if anything) needs
to be changed for the wrapper code generated by SWIG. For background
see ruby-talk messages 23358 and 38856 (and related threads).
*** Add support for keyword arguments (by collecting them in a hash?).
[DONE] Add support for defining nested modules. This should work like it does
for the SWIG Perl module.
[DONE] In a post to the SWIG users' mailing list (June 5: "Multiple Inheritance
and Ruby"), Brett Williams suggested a workaround for supporting
multiple inheritance in the Ruby module. I'm quoting it here since
the idea may be best implemented at the core level for reuse by other
language modules that have limited support for MI:
"""
While it makes for longer generated wrapper code, you can easily
generate wrappers as Ruby methods on the derived class in these cases,
i.e.:
class Base1;
class Base2;
class Derived : public Base1, public Base2;
class OtherDerived : public Base2;
This would mean that for class Derived, the methods for Base2 would be
generated as methods on class Derived as opposed to a superclass. For
class OtherDerived, things work as normal, and any other derived class
from Base2 would still work as they currently are, unless other derived
classes also use MI. The exception and extra wrapper generation would
only kick in with the use of multiple inheritance where the base class
information is available to SWIG.
The feature could be turned on and off, and doesn't have to be default
if necessary.
I was under the impression that the Tcl module, until a few releases ago,
did all inheritance this way (generating wrappers for superclass methods
in all derived classes). It does bloat the wrapper code, but in this case
it would only be causing more bloat in cases where the alternative is
no support.
What is missing with this? Hmmmm... if Base2 implements a method that is
overridden by Derived, then you could not get at Base2::Method() via the
super keyword... what else am I missing? Again, the alternative is no
support for MI at all unless you want to get fancy with mixins. I'm not
sure how good of an idea that is or even if it is workable.
"""
Another problem (which we can't really get around anyways) is that
basic inheritance relationships wouldn't be true at the Ruby level,
e.g. Derived#is_a?(Base1) would return true but Derived#is_a?(Base2)
would return false.
* Add some special directives to automatically rename declarations to
or from CamelCase.
[DONE] Consider adding a switch to define everything in the global (Kernel)
module instead of nested in a user-defined module, but only if
it comes up.
Java
----
@ -341,28 +217,19 @@ Java
at present. An overridden method for each default argument could be
generated thereby enabling one to call methods with default arguments.
[DONE] Implement idea from Dave Dribin email to the swig mailing list, 2 April 2003,
where the global enums and constants are placed in an interface so that they
can be implemented by other Java classes. This will allow improved syntax when
referring to the enums/constants:
int foo = enumname;
instead of
int foo = ModuleName.enumname;
C#
--
[DONE] Need a way to throw a C# exception from the PINVOKE C/C++ code.
[DONE] The correct override/virtual keywords not always emitted for polymorphic
methods. It currently works with 'virtual' is specified in a derived
C++ class function. A polymorphic method need not specify 'virtual' in C++.
[DONE] Wrap C/C++ enums with C# enums, currently they are wrapped with a C# int.
**** Implement director support for C# so that virtual methods work seemlessly
when mixing C# and C++ code.
**** Fix exception handling. Currently memory leaks occur when a C# exception
is thrown from C/C++.
**** Default argument support - see Java above.
PHP
---