diff options
| author | William S Fulton <wsf@fultondesigns.co.uk> | 2010-05-29 21:24:08 +0000 |
|---|---|---|
| committer | William S Fulton <wsf@fultondesigns.co.uk> | 2010-05-29 21:24:08 +0000 |
| commit | 27056fbd9f7e246aea3a6f85dcd0304679f5210e (patch) | |
| tree | 301011b54c021161044641ef548f19c5e5044ecb | |
| parent | 69db2257cb3d1ec62f327d67211483d57a3ab270 (diff) | |
| download | swig-27056fbd9f7e246aea3a6f85dcd0304679f5210e.tar.gz | |
Tidy up for first 2.0 release. Move release notes summary into new file RELEASENOTES
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@12069 626c5289-ae23-0410-ae9c-e8d60b6d4f22
| -rw-r--r-- | ANNOUNCE | 13 | ||||
| -rw-r--r-- | COPYRIGHT | 13 | ||||
| -rw-r--r-- | FUTURE | 335 | ||||
| -rw-r--r-- | Misc/fileheader | 10 | ||||
| -rw-r--r-- | NEW | 267 | ||||
| -rw-r--r-- | README | 342 | ||||
| -rw-r--r-- | RELEASENOTES | 223 | ||||
| -rw-r--r-- | swig.spec.in | 2 |
8 files changed, 268 insertions, 937 deletions
@@ -2,13 +2,10 @@ http://www.swig.org - -We're pleased to announce SWIG-2.0.0, the latest installment in the -SWIG development effort. SWIG-2.0.0 includes a number of bug fixes -and enhancements. +We're pleased to announce SWIG-2.0.0, 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 @@ -20,8 +17,8 @@ SWIG include generation of scripting language extension modules, rapid prototyping, testing, and user interface development for large C/C++ systems. -Availability: -------------- +Availability +============ The release is available for download on Sourceforge at http://prdownloads.sourceforge.net/swig/swig-2.0.0.tar.gz @@ -30,7 +27,7 @@ A Windows version is also available at http://prdownloads.sourceforge.net/swig/swigwin-2.0.0.zip -Please report problems with this release to the swig-dev mailing list, +Please report problems with this release to the swig-devel mailing list, details at http://www.swig.org/mail.html. --- The SWIG Developers @@ -61,3 +61,16 @@ Past contributors include: Kovuk, Oleg Tolmatcev, Tal Shalif, Lluis Padro, Chris Seatory, Igor Bely, Robin Dunn (See CHANGES and CHANGES.current for a more complete list). +Historically, the following people contributed to early versions of SWIG. +Peter Lomdahl, Brad Holian, Shujia Zhou, Niels Jensen, and Tim Germann +at Los Alamos National Laboratory were the first users. Patrick +Tullmann at the University of Utah suggested the idea of automatic +documentation generation. John Schmidt and Kurtis Bleeker at the +University of Utah tested out the early versions. Chris Johnson +supported SWIG's developed at the University of Utah. John Buckman, +Larry Virden, and Tom Schwaller provided valuable input on the first +releases and improving the portability of SWIG. David Fletcher and +Gary Holt have provided a great deal of input on improving SWIG's +Perl5 implementation. Kevin Butler contributed the first Windows NT +port. + diff --git a/FUTURE b/FUTURE deleted file mode 100644 index 997de9b4c..000000000 --- a/FUTURE +++ /dev/null @@ -1,335 +0,0 @@ -SWIG-1.3.12, SWIG 2.0, and Beyond -================================= - -With the release of SWIG-1.3.12, I thought I'd take a few moments of -everyone's time to talk about the past, the present, and the future of -SWIG development. I'm really quite excited about the current release -because I think it represents a huge turning point in SWIG's -development. Furthermore, it is only the beginning of bigger and -better things to come. However, we definitely need your help. - -To put a little perspective on the discussion, I'd start with a few -development statistics. In the last 12 months, there have been over -300 entries added to the CHANGES log and over 4000 CVS commits. -Although that may not sound like a lot compared to a huge software -project, it is significant in the context of SWIG. As a point of -comparison, there has been more SWIG development this year than in any -other year of the project and more than in the previous three years -combined. This even includes the first few years of development in -which there was also a lot of activity. Furthermore, many of the -recent changes have been extremely non-trivial (e.g., templates, -namespaces, type system, operators, etc.). As a result, SWIG is more -capable than I ever imagined possible. - -Regrettably, I must admit that I've been a little negligent in -discussing the roadmap for where I thought this flurry of SWIG -development was actually headed. In part, this is because I've been -buried in work. However, the real reason is that I didn't really know -where we were going---except that in a time far far far away in the -future, we might arrive at some kind of "stable" release with a -version number other than "1.3.x". Needless to say, that's not a very -compelling story. - -That said, I've spent a lot of time thinking about SWIG and trying to -wrap my brain around it. Specifically, just what is (or should be) -the primary focus of this project and what are we really trying to do? -That's what the rest of this message is about. - -SWIG Prehistory ---------------- -The first version of SWIG was written in 1995. The original system -was developed to help with some software wrapping problems I -encountered while writing molecular dynamics software at Los -Alamos. Later that year, I became interested in extending the wrapper -generator to support other scripting languages so it was rewritten in -C++ and modified with multiple backends (Tcl, Perl, and Guile). This -led to a first public release in February, 1996. Feedback from this -release led to a series of enhancements and the release of SWIG 1.0 in -September 1996. Throughout this process, my intent was to create a -tool that I would want to use---I never viewed the project as an -CS experiment in programming languages or software engineering. - -SWIG 1.1 --------- -SWIG-1.1 (June, 1997) represented a series of enhancements that were -added in response to feedback at conferences and from users. Shadow -classes, exception handling, typemaps, and a number of more useful -features were added. However, the overall structure of the system was -relatively unchanged from the initial version. Following the release -of 1.1, a series of minor patch releases were made. This resulted in -the release of SWIG-1.1p5 in February, 1998. Unfortunately, this -release would remain the last "stable" release for quite a long -time---in fact, it is still listed as the last "stable" release on the -SWIG web page! - -SWIG Hell ---------- -Even during the development of SWIG-1.1, it was clear that the whole -design of the system was deeply flawed. The implementation was a mess -and the C/C++ support was full of holes and nasty corner cases. -Furthermore, there was no unifying principle that tied all of the -different SWIG directives together. Not only that, fixing these -problems appeared to be nothing short of impossible---requiring a -total ground-up rewrite at best. The only redeeming quality was that -the system basically worked "well enough," it was extensively -documented, and its flaws mostly known. People could use it and there -were work-arounds for most common problems. - -To deal with the design problem, there were at least four attempts to -completely rewrite SWIG, some of which were attempted in parallel with -the work on SWIG-1.1. Unfortunately, none of these were ever -completed. The primary problem was a strong "second system" effect and -a desire to make SWIG do everything that one might conceivably want to -do with a wrapper generator (somehow). Clearly, this was a recipe for -disaster. In fact, all such attempts to rewrite SWIG were eventually -abandoned several years ago. In hindsight, I think the real problem -was that these rewrite efforts focused far too much attention on -implementation technique rather than principles. In short, the -failure of these efforts was due to a lack of clarity in understanding -how SWIG ought to work (regardless of how it was actually -implemented). - -SWIG Restart (1.3a1-1.3a5) --------------------------- -Having languished for several years, the SWIG1.1p5 release had a -growing pile of maintenance issues. It didn't work for newer versions -of certain language modules and a lot of minor bug reports and feature -requests had been building up. With a lot of help from Loic Dachary and -Thien-Thi Nguyen, we put together the 1.3a1 release (February, -2000). This was mostly a bug fix release to 1.1p5 except that the -preprocessor module from SWIG1.2 was added and a lot of minor -enhancements were added. - -For the next six months, a massive effort was made to rewrite all of -SWIG's internal data structures (strings, lists, hashes, etc.). This -work was all going on underneath the covers while we tried to keep -SWIG in an operational state. The primary focus of this work was -really one of cleanup. Having given up on a total rewrite, perhaps -we could settle with making the implementation incrementally better -than before. In addition this, Matthias Koppe jumped on board to -reimplement the Guile module and to make other improvements to the system. - -An important aspect of these releases was that many parts of the -system not directly related to wrapper code generation were removed. -This included the documentation system and Objective-C support. These -were not removed because they weren't useful. Instead, the -documentation system was removed because it accounted for nearly half -of the special SWIG directives, yet had no direct bearing on what SWIG -actually did. Obective-C support was removed because it was tangled -with C++ support in a way that was very difficult to understand and -maintain. The removal of these features was seen as a way to vastly -simplify cleanup--and to buy some time where we could rethink their -role in a future release. - -SWIG Redux (1.3.6-1.3.11) -------------------------- -This work, started in February 2001, is the beginning of the current -SWIG implementation. With the help of William Fulton, Matthias Koppe, -Lyle Johnson, Luigi Ballabio, Jason Stewart, Richard Palmer, Sam -Liddicot, and others, this work can best be described as the wholesale -destruction of everything remaining from SWIG-1.1. The language -module API, type system, the parser, numerous SWIG directives, and -SWIG library files---all destroyed or rewritten. Not only that, we -started introducing significant incompatibilities with -SWIG-1.1---mostly in an effort to correct past wrongs and get -ourselves out of the tangled mess of earlier versions. A huge number -of long-standing bugs and difficult feature requests have also been -resolved. - -The general goal of this development could best be described as an -attempt to reduce SWIG to an easily described set of general "ideas" -about how it should operate. Special SWIG directives have been -eliminated or combined with others. Different parts of the system have -been better integrated. Features not directly related to wrapper code -generation have been removed and the system has become more -focused. Changes in internal data structures and APIs have allowed -SWIG to capture more information from interface files and to resolve -hard corner cases. More often than not, these are things that you -never notice unless you are an old user and you suddenly realize that -a problem you had several years back has disappeared. - -Along with the destruction of old code, this work has quietly -introduced a new core--the most significant features of which are a -new C++ type system and multi-pass compilation. More importantly, -this work has really tried to provide a more principled foundation for -future SWIG development. However, just what is this "more principled -foundation?" - -Convergence (1.3.12) --------------------- -With the upcoming 1.3.12 release, SWIG is about to take a big leap -forward. Almost all of this is due to one realization---that almost -every hard problem in past SWIG releases has been directly related to -errors and limitations in its type system. Types are the key to -understanding the structure of C and C++ code. They are at the heart -of understanding advanced language features like namespaces, nested -classes, and templates. They are directly related to the data -marshalling that occurs in wrappers. Not only that, they interact -with nearly every SWIG directive. A proper type system *is* the -necessary foundation for moving SWIG forward. - -To be honest, I don't think that the emphasis on types is entirely -obvious. In fact, a great deal of work in past SWIG rewrites has -focused on the problem of C++ parsing. For instance, modifying the -parser to handle more advanced C++ code or representing parse trees as -XML. Furthermore, if one looks at the SWIG mailing list, you can find -a *lot* of messages related to issues of C++ parsing whereas almost no -one ever talks about types (well, other than typemaps). Even other -wrapper generation tools seems to spend a lot of time dealing with the -parsing issue. Although parsing is clearly important, I don't think it -has ever been the real problem in SWIG. This is because even though a -parser can tell you what's in a header file, it doesn't tell you -anything about how the different pieces of the system behave or how -they might interact. To do that, you need to do a lot more than just -parsing--and that's really the whole point. - -Although earlier 1.3 releases have made big improvements to the type -system, SWIG-1.3.12 is the first release that really tries to tackle -the type-system issue in a major way. We have patched nearly all -remaining holes in the type system and we have added full support for -C++ namespaces. Not only that, we have completely reimplemented C++ -template support in a way that supports templates, member templates, -and template specialization. Luigi and I are currently using this to -work on proper SWIG library support for parts of the C++ standard -library and the Standard Template Library (STL). Although some crusty -C programmers (present company excepted), might balk at such apparent -insanity, this work has impacted all parts of SWIG at all levels. -Even a variety of subtle errors in C support have been fixed by this -work. - -In addition to the type system work, SWIG-1.3.12 contains continued -reduction in the implementation. Directives have been removed, -refined, renamed, or consolidated. We're still narrowing the focus of -the system and working towards some kind of convergence. "Convergence -to what?!?", you ask. - -So, what is SWIG? ------------------ -In a nutshell, SWIG is a C/C++ declaration compiler that generates -wrapper code (okay, so you knew that much). However, to really -understand what SWIG is doing and where SWIG-1.3.x is headed, it is -useful to know that the whole system is essentially being built around -three extensions to the C++ type system: - - - Typemaps. Typemaps are rules that define the process by which - data is converted between languages. They are fully integrated - with the C++ type system and they are applied using a type-based - pattern matching mechanism. All data conversion SWIG is - defined by typemaps and is fully reconfigurable. - - - Declaration annotation. There are special directives that modify - the wrapping behavior of individual declarations. Declarations - can be selectively identified and decorated with arbitrary - attributes that affect wrapper generation. Like typemaps, - declaration matching is fully integrated with the C++ type system. - Almost all SWIG customization directives are a form of declaration - annotation. - - - Class extension. The ability to extend classes and structures - with new methods/attributes when building wrappers. Classes - are part of the type system so class extension is naturally - integrated with the C++ type system as well (big surprise). - -And that's it--this is the end-game of SWIG-1.3.x development. When -stabilized and documented it will become SWIG-2.0. - -The Bigger Picture ------------------- -I really want to emphasize that all of this work is part of a much -bigger picture. SWIG is used by a surprising number of people in -industry, government, and academia. It's used to build systems used -by millions of people every day. It has even shown up in video games -and other unlikely settings. Although SWIG doesn't have the same -visibility as many large software projects, over 12000 people have -downloaded SWIG-1.3.11 in the last 4 months. Clearly someone is using -it for something! Because of this, I think it is important for us to -work on moving SWIG towards a more solid foundation. Doing so will -give the system more credibility and long term viability---and it will -be a lot more fun to use! - -It's also worth noting that there are some rather interesting CS -connections at work here. Extensions to the type system and typemaps -have some interesting relations to work in programming languages. The -SWIG declaration annotation system and class extension feature seem -oddly similar to work in the emerging area of Aspect Oriented -Programming (AOP). There are undoubtedly connections to other areas -of software engineering and architecture. - -The key point is that SWIG isn't going to connect to anything if -no-one can quite describe what it is or how it works. - -SWIG-2.0 and the Future ------------------------ -SWIG-1.3.12 still represents work in progress. There are bugs, the -documentation is still incomplete, and there are parts of the -implementation that are rather ugly. We are also still working out a -few very hard problems like nested classes, callback functions, and -overloading. A few old features are still missing (Objective-C, -documentation). However, I believe the end of the 1.3.x series is -near and achievable. - -Over the summer, a few more 1.3.x releases may appear but the current -plan is to aim for a SWIG-2.0 release in September. This release is -really moving towards the design principles described above and will -be a very major enhancement over SWIG-1.1. - -As for the future, a number of interesting ideas are on the table. I -want to add support for contracts/assertions in order to solve some -reliability issues that arise when retrofitting legacy codes with a -scripting interface. Support for an extension language has been -promoted by David Fletcher and was suggested by someone else on the -mailing list rather recently. I have a graduate student working on -SWIG support for the Microsoft CLR and .NET languages. Other work -might include support for alternative parsers, dynamically loadable -language modules, and so forth. However, none of this is really going -to materialize if we can't get the 2.0 release stablized. In fact, I -see SWIG-2.0 as a necessary step for moving forward with these ideas. - -We need your help! Yes, you. ----------------------------- -Nobody gets paid to work on SWIG. The developers are volunteers who -work in their spare time. Furthermore, SWIG is not supported by -investors, a large corporation, or research grants. I work on it -because it's fun, challenging, and useful. I presume that other -developers do the same. However, we only have limited resources and -we need your help. - -- If you like SWIG and find it useful, we need you to try new versions. - We want you to torture test the releases and to break them. We need - bug reports. No bug is too obscure or unimportant---we *will* fix it - if we can. We also need feedback about things that are annoying or - compatibility features that might help in going from 1.1 to 2.0. - -- We need help with documentation, examples, testing, libraries, and all - sorts of other aspects of the release. Even if you have never - written a SWIG language module or dived into its implementation, - there are many ways that you can help. Consider writing a case study - about how you wrapped a big library. Contribute tests that break the - implementation in horrible ways. Help with the web page or FAQ. - -- Most of the SWIG-1.3.x work has focused on the SWIG core. However, as - the 2.0 release nears, we will be working on a variety of enhancements - to the language modules. If there are things you would like to see - in any of the language modules, you need to let us know. - -- There are SWIG language modules that have not made it into the - distribution. Examples that I know about include ITCL, Swig-Eiffel, - and Swig-Lua. We would gladly make these part of the standard SWIG - distribution. However, we also need help to do it. Porting from - SWIG-1.1 is no easy task, but we're more than willing to help. It's - not as bad as one might imagine. - -- We are always looking for developers. Subscribe to - the swig-dev mailing list, details at http://www.swig.org/mail.html, - or send me email to get involved. - -Acknowledgements ----------------- -I'd just like to thank everyone who has submitted feedback, bugs, made -contributions, and put up with my occasional thrashing over the years. -I welcome any comments about this document and how we can make SWIG even -better. - -Dave Beazley (beazley@cs.uchicago.edu) -June 2, 2002 - diff --git a/Misc/fileheader b/Misc/fileheader deleted file mode 100644 index dcdbdeb75..000000000 --- a/Misc/fileheader +++ /dev/null @@ -1,10 +0,0 @@ -/* ----------------------------------------------------------------------------- - * file.c - * - * This file does a bunch of stuff. - * - * Author(s) : David Beazley (beazley@cs.uchicago.edu) - * - * Copyright (C) 1999-2000. The University of Chicago - * See the file LICENSE for information on usage and redistribution. - * ----------------------------------------------------------------------------- */ @@ -1,267 +0,0 @@ -New Features and Important Changes, v1.3 - -Author(s) : David Beazley - -March 21, 2003 - -1. Introduction ---------------- -This document briefly explains some of the most important changes made -since the release of SWIG1.1. The goal is to provide information for -people who want to upgrade an older SWIG interface to the new version. - -Most changes pertain to the internal implementation of SWIG and the -organization of the core, parser, and language modules. As a SWIG -user, almost all of these changes are hidden from view except for a -few important cases where changes to the core have dramatically -altered SWIG's old behavior. - -2. Types and typemaps ---------------------- -2.1 Variables of the form 'const type *' are no longer wrapped as - constants, but as C global variables. The earlier SWIG behavior - was incorrect due to Dave's misinterpretation of 'const' in the C - language specification. - - If you have written an interface that expects to create - constants using 'const type *' you will need to rewrite those - specifications using a new %constant directive like this: - - %constant(type *) name = value; - -2.2 SWIG generally has better support for pointers, 'const', - arrays, and pointers to functions. - -2.3 Typemaps are now applied to a more precisely defined set - of datatypes. For example, consider the following - typemap: - - %typemap(in) foo * { - ... get a foo ... - } - - In SWIG1.1, this typemap would get applied to 'foo *', - 'foo &', 'foo []', 'foo[][]', and so forth. - - In SWIG1.3, this typemap *only* gets applied to 'foo *' and - 'const foo *'. It does *NOT* get mapped to the other - variants listed above. - -2.4 Bug fix. SWIG now correctly handles typemaps of the form - - %typemap(in) Object { - ... get an object ... - } - -2.5 The memberout typemap is no longer available and is withdrawn. - The old implementation was essentially useless because of the - way in which code was generated. - -2.6 The memberin typemap is now inserted inline in the generated - wrapper code. This provides access to scripting-specific - variables in the wrapper function. - -2.7 SWIG-1.3.10 features a total rewrite of the typemap system. - Typemaps now use a different variable naming scheme. Typemaps - for arguments look like this: - - %typemap(in) sometype { - $1 = convert value ($input); - } - - The variable $1 replaces $target and the variable $input replaces - $source. - - For output values, typemaps look like this: - - %typemap(out) sometype { - $result = create result ($1); - } - - The variable $1 replaces $source and the variable $result replaces - $target. - - See Doc/Manual/Typemaps.html for a full description of the new - typemap system. - -2.8 Multi-argument typemaps are now supported. This solves a common - problem that occurs with functions like this - - void foo(char *buffer, int len); - - where you would like to make the two arguments operate as a single - object in the target language. - -2.9 Types such as 'const int &', 'const double &', are passed as - values instead of pointers. - -2.10 C++ namespaces are now supported. - -3. Type checking ----------------- - -SWIG no longer uses the functions SWIG_GetPtr() and SWIG_MakePtr() to -parse datatypes in wrapper code. This is because the type of a -pointer is no longer associated with a string, but with a special -"swig_type_info *" object. If you are not using typemaps, this change -should cause no noticable effects. However, if you have written -typemaps to handle pointers, here are the essential details: - -3.1 Type name mangling is different in SWIG1.3. For a type of - "int **", SWIG1.1 used to produce a name of the form - "_int_pp". SWIG1.3 on the other hand, produces a name - of the form "_p_p_int". There are a number of reasons for - changing the format, but I'd rather not go into it here. You'll - just have to learn to live with it :-). - -3.2 Types are described by a special "swig_type_info *" object. Everywhere - a string was used before, an object of this type will be used. - The "swig_type_info *" for a given type can always be obtained - using macros involving the mangled typename in 3.1. For example, - the type object of of 'int **' is 'SWIGTYPE_p_p_int'. - -3.3 Instead of SWIG_GetPtr, a function of the following form is used: - - int SWIG_ConvertPtr(ScriptObj *o, void **ptr, swig_type_info *ty, int flags); - - Note: the function name may differ in certain implementations (read - the source). For example: - - int SWIG_ConvertPtr(ScriptObj *o, void **ptr, SWIGTYPE_p_p_int,0); - - Passing a value of '0' for the type will accept any pointer. This - works kind of like 'void *'. The flags argument is reserved for - future expansion. - -3.4. To create a pointer object, one uses a function similar to - - ScriptObj *SWIG_NewPointer(void *ptr, swig_type_info *ty, int flags); - - It works in a similar manner: - - p = SWIG_NewPointer(ptr, SWIGTYPE_p_p_int, 0); - - You will have to read the source to get the exact function name - used. The flags argument is implementation specific and reserved - for future expansion. - -3.5. If, for whatever reason, you need to obtain the 'swig_type_info *' - outside the context of a wrapper file, you can use the - SWIG_TypeQuery() function. For example: - - swig_type_info *ty = SWIG_TypeQuery("int **"); - - this function returns an appropriate type_info structure or NULL - if no such type is registered. - -3.6 SWIG does not generate swig_type_info structures for types that are - not actually used in an interface file. As a result, the type - checking tables for SWIG1.3 tend to be much smaller than for SWIG1.1. - -*** Note: The old string-based type checking scheme is not going to -return to SWIG so do not ask for backwards compatibility. The new -scheme is substantially faster, it is less error-prone, it requires no -dynamic memory allocation, it works better with the runtime libraries, -and it is simpler to implement than the old string based approach. - -4. Deprecated Features (incomplete list) ----------------------------------------- - -4.1 Documentation system. The old documentation system has been removed - entirely. I expect it to return someday, but it will have a much - different form (probably influenced by XML). - -4.2 The %val and %out directives. These directives used to attach - properties to function parameters such as - - void foo(%val int *ptr); - - The same effect can now be achieved with typemaps: - - void foo(int *INPUT); - - -4.3 Extensions to the %module and %init directive are no longer - supported. For example: - - %module example, foo, bar - - This used to perform a special kind of multi-module - initialization for static linking. If you really - need to do this, you will have to manually insert - code into the module initialization function. - -4.4 %ifdef, %ifndef, %endif, %if, %elif, %else directives are - withdrawn. SWIG now has a real preprocessor. - -4.5 %checkout directive removed. - -4.6 %except and %new are deprecated. - -4.7 %readonly and %readwrite are deprecated. Use %immutable instead. - -4.8 The %addmethods directive has been renamed to %extend. - -5. Language specific changes ----------------------------- - -5.1 Python shadow classes are much more efficient and pass the shadow objects - directly to the C wrappers. - -5.2 Tcl code generation is substantially improved--especially for C++. - -5.3 Tcl module can now link to global variables of any type. - -5.4 Perl shadow classes improved and optimized somewhat. - -5.5 The Guile module represents pointers as smobs. (They used to be - mangled into strings.) Memory leaks and type conversion bugs have been - fixed. The Guile module system, including dynamic loading, and - exceptions are supported. A typemap-driven procedure-documentation - system has been added (requires Guile 1.4). Procedures-with-setters - can be generated. - -5.6 The Python module now automatically creates shadow class objects from the - C wrappers. This fixes a bunch of hard problems related to typemaps, - exception handling, and more. - -6. New Features ---------------- - -6.1 Java module added - -6.2 Ruby module added - -6.3 Mzscheme module added. - -6.4 Integrated preprocessor. You can now use C macros in SWIG interface files. - -6.5 PHP module added. - -6.6 %rename directive is greatly enhanced to deal with overloaded functions. - -6.7 Support for simple templates - -6.8 Support for overloaded operators. - -6.9 %feature directive. - -6.10 Ocaml module added. - -6.11 XML module added. - -6.12 CHICKEN module added. - -6.13 C# module added. - - - - - - - - - - - - @@ -12,318 +12,36 @@ code) in order to make the corresponding C/C++ libraries available to the listed languages, or to extend C/C++ programs with a scripting language. -This distribution represents the latest development release of SWIG. - Up-to-date SWIG related information can be found at http://www.swig.org A SWIG FAQ and other hints can be found on the SWIG Wiki: - http://www.dabeaz.com/cgi-bin/wiki.pl - - -!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -!!!!!!! IMPORTANT !!!!!!! -!!!!!!! !!!!!!! -!!!!!!! Previous SWIG-1.1 users should read the documentation !!!!!!! -!!!!!!! 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. !!!!!!! -!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! - -What's New? -=========== - -SWIG-1.3.40 summary: -- SWIG now supports directors for PHP. -- PHP support improved in general. -- Octave 3.2 support added. -- Various bug fixes/enhancements for Allegrocl, C#, Java, Octave, Perl, - Python, Ruby and Tcl. -- Other generic fixes and minor new features. - -SWIG-1.3.39 summary: -- Some new small feature enhancements. -- Improved C# std::vector wrappers. -- Bug fixes: mainly Python, but also Perl, MzScheme, CFFI, Allegrocl - and Ruby - -SWIG-1.3.38 summary: -- Output directory regression fix and other minor bug fixes - -SWIG-1.3.37 summary: -- Python 3 support added -- SWIG now ships with a version of ccache that can be used with SWIG. - This enables the files generated by SWIG to be cached so that repeated - use of SWIG on unchanged input files speeds up builds quite considerably. -- PHP 4 support removed and PHP support improved in general -- Improved C# array support -- Numerous Allegro CL improvements -- Bug fixes/enhancements for Python, PHP, Java, C#, Chicken, Allegro CL, - CFFI, Ruby, Tcl, Perl, R, Lua. -- Other minor generic bug fixes and enhancements - -SWIG-1.3.36 summary: -- Enhancement to directors to wrap all protected members -- Optimisation feature for objects returned by value -- A few bugs fixes in the PHP, Java, Ruby, R, C#, Python, Lua and - Perl modules -- Other minor generic bug fixes - -SWIG-1.3.35 summary: -- Octave language module added -- Bug fixes in Python, Lua, Java, C#, Perl modules -- A few other generic bugs and runtime assertions fixed - -SWIG-1.3.34 summary: -- shared_ptr support for Python -- Support for latest R - version 2.6 -- Various minor improvements/bug fixes for R, Lua, Python, Java, C# -- A few other generic bug fixes, mainly for templates and using statements - -SWIG-1.3.33 summary: -- Fix regression for Perl where C++ wrappers would not compile -- Fix regression parsing macros - -SWIG-1.3.32 summary: -- shared_ptr support for Java and C# -- Enhanced STL support for Ruby -- Windows support for R -- Fixed long-standing memory leak in PHP Module -- Numerous fixes and minor enhancements for Allegrocl, C#, cffi, Chicken, Guile, - Java, Lua, Ocaml, Perl, PHP, Python, Ruby, Tcl. -- Improved warning support - -SWIG-1.3.31 summary: -- Python modern classes regression fix - -SWIG-1.3.30 summary: -- Python-2.5 support -- New language module: R -- Director support added for C# -- Numerous director fixes and improvements -- Improved mingw/msys support -- Better constants support in Guile and chicken modules -- Support for generating PHP5 class wrappers -- Important Java premature garbage collection fix -- Minor improvements/fixes in cffi, php, allegrocl, perl, chicken, lua, ruby, - ocaml, python, java, c# and guile language modules -- Many many other bug fixes - -SWIG-1.3.29 summary: -- Numerous important bug fixes -- Few minor new features -- Some performance improvements in generated code for Python - -SWIG-1.3.28 summary: -- More powerful renaming (%rename) capability. -- More user friendly warning handling. -- Add finer control for default constructors and destructors. We discourage - the use of the 'nodefault' option, which disables both constructors and - destructors, leading to possible memory leaks. Use instead 'nodefaultctor' - and/or 'nodefaultdtor'. -- Automatic copy constructor wrapper generation via the 'copyctor' option/feature. -- Better handling of Windows extensions and types. -- Better runtime error reporting. -- Add the %catches directive to catch and dispatch exceptions. -- Add the %naturalvar directive for more 'natural' variable wrapping. -- Better default handling of std::string variables using the %naturalvar directive. -- Add the %allowexcept and %exceptionvar directives to handle exceptions when - accessing a variable. -- Add the %delobject directive to mark methods that act like destructors. -- Add the -fastdispatch option to enable smaller and faster overload dispatch - mechanism. -- Template support for %rename, %feature and %typemap improved. -- Add/doc more debug options, such as -dump_module, -debug_typemaps, etc. -- Unified typemap library (UTL) potentially providing core typemaps for all - scripting languages based on the recently evolving Python typemaps. -- New language module: Common Lisp with CFFI. -- Python, Ruby, Perl and Tcl use the new UTL, many old reported and hidden - errors with typemaps are now fixed. -- Initial Java support for languages using the UTL via GCJ, you can now use - Java libraries in your favorite script language using gcj + swig. -- Tcl support for std::wstring. -- PHP4 module update, many error fixes and actively maintained again. -- Allegrocl support for C++, also enhanced C support. -- Ruby support for bang methods. -- Ruby support for user classes as native exceptions. -- Perl improved dispatching in overloaded functions via the new cast and rank - mechanism. -- Perl improved backward compatibility, 5.004 and later tested and working. -- Python improved backward compatibility, 1.5.2 and later tested and working. -- Python can use the same cast/rank mechanism via the -castmode option. -- Python implicit conversion mechanism similar to C++, via the %implicitconv - directive (replaces and improves the implicit.i library). -- Python threading support added. -- Python STL support improved, iterators are supported and STL containers can - use now the native PyObject type. -- Python many performance options and improvements, try the -O option to test - all of them. Python runtime benchmarks show up to 20 times better performance - compared to 1.3.27 and older versions. -- Python support for 'multi-inheritance' on the python side. -- Python simplified proxy classes, now swig doesn't need to generate the - additional 'ClassPtr' classes. -- Python extended support for smart pointers. -- Python better support for static member variables. -- Python backward compatibility improved, many projects that used to work - only with swig-1.3.21 to swig-1.3.24 are working again with swig-1.3.28 -- Python test-suite is now 'valgrinded' before release, and swig also - reports memory leaks due to missing destructors. -- Minor bug fixes and improvements to the Lua, Ruby, Java, C#, Python, Guile, - Chicken, Tcl and Perl modules. - -SWIG-1.3.27 summary: -- Fix bug in anonymous typedef structures which was leading to strange behaviour - -SWIG-1.3.26 summary: -- New language modules: Lua, CLISP and Common Lisp with UFFI. -- Big overhaul to the PHP module. -- Change to the way 'extern' is handled. -- Minor bug fixes specific to C#, Java, Modula3, Ocaml, Allegro CL, - XML, Lisp s-expressions, Tcl, Ruby and Python modules. -- Other minor improvements and bug fixes. - -SWIG-1.3.25 summary: -- Improved runtime type system. Speed of module loading improved in - modules with lots of types. SWIG_RUNTIME_VERSION has been increased - from 1 to 2, but the API is exactly the same; only internal changes - were made. -- The languages that use the runtime type system now support external - access to the runtime type system. -- Various improvements with typemaps and template handling. -- Fewer warnings in generated code. -- Improved colour documentation. -- Many C# module improvements (exception handling, prevention of early - garbage collection, C# attributes support added, more flexible type - marshalling/asymmetric types.) -- Minor improvements and bug fixes specific to the C#, Java, TCL, Guile, - Chicken, MzScheme, Perl, Php, Python, Ruby and Ocaml modules). -- Various other bug fixes and memory leak fixes. - -SWIG-1.3.24 summary: -- Improved enum handling -- More runtime library options -- More bugs fixes for templates and template default arguments, directors - and other areas. -- Better smart pointer support, including data members, static members - and %extend. - -SWIG-1.3.23 summary: -- Improved support for callbacks -- Python docstring support and better error handling -- C++ default argument support for Java and C# added. -- Improved c++ default argument support for the scripting languages plus - option to use original (compact) default arguments. -- %feature and %ignore/%rename bug fixes and mods - they might need default - arguments specified to maintain compatible behaviour when using the new - default arguments wrapping. -- Runtime library changes: Runtime code can now exist in more than one module - and so need not be compiled into just one module -- Further improved support for templates and namespaces -- Overloaded templated function support added -- More powerful default typemaps (mixed default typemaps) -- Some important %extend and director code bug fixes -- Guile now defaults to using SCM API. The old interface can be obtained by - the -gh option. -- Various minor improvements and bug fixes for C#, Chicken, Guile, Java, - MzScheme, Perl, Python and Ruby -- Improved dependencies generation for constructing Makefiles. - -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 *. -- Initial support for Modula3 and Allegro CL. -- 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, Python, 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. - - Support for C++ namespaces - - Support for C++ overloaded operators. - - Support for C++ templates including member templates. - - Support for C++ template specialization and partial specialization. - - Support for C++ friend declarations. - - Parsing support for almost all C/C++ datatypes. - - Automatic translation of C++ exception specifiers. - - Contract support. - - A full C preprocessor with macro expansion. Includes C99 variadic macros. - - Java, Ruby, MzScheme, PHP4, OCAML, Pike, CHICKEN, XML and C# modules - added. Guile module improved. - - Director support - upcalls for C++ virtual functions into the target - language proxy class. - - Better code generation. SWIG is better able to make optimizations - in order to generate less code. - - Testing framework part of the distribution ("make -k check" support). - - A lot of minor bug fixes and cleanup. - - Better Windows support. - -If you used SWIG-1.1, a number of old features are missing from SWIG-1.3. - - - 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 - included. - - - A wide variety of old SWIG command-line options and - obscure features are gone. - - - A lot of old %pragma directives and obscure undocumented - customization features have been eliminated. The same - functionality is now available through other means. - - - Objective C support doesn't work right now. No ETA as to - when it will return. - -Although we are making some attempt to preserve backwards -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 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 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, 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. + http://www.dabeaz.com/cgi-bin/wiki.pl -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. +License +======= +Please see the LICENSE file for details of the SWIG license. Release Notes ============= Please see the CHANGES.current file for a detailed list of bug fixes and new features for the current release. The CHANGES file contains bug fixes -and new features for older versions. A summary of the changes is included -in this README file. +and new features for older versions. A summary of changes in each release +can be found in the RELEASENOTES file. + +Backwards Compatibility +======================= +The developers strive their best to preserve backwards compatibility +between releases, but this is not always possible as the overriding +aim is to provide the best wrapping experience. Where backwards +compatibility is known to be broken, it is clearly marked as an +incompatibility in the CHANGES and CHANGES.current files. + +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. Windows Installation ==================== @@ -380,8 +98,9 @@ examples which build the runtime library. Notes: (1) If you checked the code out via SVN, you will have to run ./autogen.sh - before typing 'configure'. In addition, a full build of SWIG requires - the use of bison. + before typing 'configure'. In addition, a full build of SWIG requires + the a number of packages to be installed. Full instructions at + http://www.swig.org/svn.html Macintosh OS X Installation ============================ @@ -389,15 +108,13 @@ 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. We've tried to resolve these differences to the extent of our knowledge. -This release was most recently checked with the Panther release of OS X on a -Macintosh G5 system. Your mileage may vary. 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 (-flat_namespace -undefined suppress). This mostly closely follows the Unix +symbols (-flat_namespace -undefined suppress). 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 +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 @@ -435,7 +152,7 @@ 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. -Note: The test-suite currently contains around 250 tests. If you +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. @@ -490,16 +207,11 @@ Documentation The Doc/Manual directory contains the most recent set of updated documentation for this release. The documentation is available in three different formats, each of which contains identical content. -These format are, pdf (SWIGDocumentation.pdf), single +These format are, pdf (Doc/Manual/SWIGDocumentation.pdf), single page html (Doc/Manual/SWIGDocumentation.html) or multiple page html (other files in Doc/Manual). Please select your chosen format and copy/install to wherever takes your fancy. -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. - There is some technical developer documentation available in the Doc/Devel subdirectory. This is not necessarily up-to-date, but it has some information on SWIG internals. @@ -511,11 +223,9 @@ 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 the swig-dev +language module to the distribution, please contact the swig-devel mailing list, details at http://www.swig.org/mail.html. -- The SWIG Maintainers - - diff --git a/RELEASENOTES b/RELEASENOTES new file mode 100644 index 000000000..da833574c --- /dev/null +++ b/RELEASENOTES @@ -0,0 +1,223 @@ +Release Notes +============= + +A summary of recent releases is described below. A more detailed description +is available in the CHANGES.current and CHANGES files. + +SWIG-1.3.40 summary: +- SWIG now supports directors for PHP. +- PHP support improved in general. +- Octave 3.2 support added. +- Various bug fixes/enhancements for Allegrocl, C#, Java, Octave, Perl, + Python, Ruby and Tcl. +- Other generic fixes and minor new features. + +SWIG-1.3.39 summary: +- Some new small feature enhancements. +- Improved C# std::vector wrappers. +- Bug fixes: mainly Python, but also Perl, MzScheme, CFFI, Allegrocl + and Ruby + +SWIG-1.3.38 summary: +- Output directory regression fix and other minor bug fixes + +SWIG-1.3.37 summary: +- Python 3 support added +- SWIG now ships with a version of ccache that can be used with SWIG. + This enables the files generated by SWIG to be cached so that repeated + use of SWIG on unchanged input files speeds up builds quite considerably. +- PHP 4 support removed and PHP support improved in general +- Improved C# array support +- Numerous Allegro CL improvements +- Bug fixes/enhancements for Python, PHP, Java, C#, Chicken, Allegro CL, + CFFI, Ruby, Tcl, Perl, R, Lua. +- Other minor generic bug fixes and enhancements + +SWIG-1.3.36 summary: +- Enhancement to directors to wrap all protected members +- Optimisation feature for objects returned by value +- A few bugs fixes in the PHP, Java, Ruby, R, C#, Python, Lua and + Perl modules +- Other minor generic bug fixes + +SWIG-1.3.35 summary: +- Octave language module added +- Bug fixes in Python, Lua, Java, C#, Perl modules +- A few other generic bugs and runtime assertions fixed + +SWIG-1.3.34 summary: +- shared_ptr support for Python +- Support for latest R - version 2.6 +- Various minor improvements/bug fixes for R, Lua, Python, Java, C# +- A few other generic bug fixes, mainly for templates and using statements + +SWIG-1.3.33 summary: +- Fix regression for Perl where C++ wrappers would not compile +- Fix regression parsing macros + +SWIG-1.3.32 summary: +- shared_ptr support for Java and C# +- Enhanced STL support for Ruby +- Windows support for R +- Fixed long-standing memory leak in PHP Module +- Numerous fixes and minor enhancements for Allegrocl, C#, cffi, Chicken, Guile, + Java, Lua, Ocaml, Perl, PHP, Python, Ruby, Tcl. +- Improved warning support + +SWIG-1.3.31 summary: +- Python modern classes regression fix + +SWIG-1.3.30 summary: +- Python-2.5 support +- New language module: R +- Director support added for C# +- Numerous director fixes and improvements +- Improved mingw/msys support +- Better constants support in Guile and chicken modules +- Support for generating PHP5 class wrappers +- Important Java premature garbage collection fix +- Minor improvements/fixes in cffi, php, allegrocl, perl, chicken, lua, ruby, + ocaml, python, java, c# and guile language modules +- Many many other bug fixes + +SWIG-1.3.29 summary: +- Numerous important bug fixes +- Few minor new features +- Some performance improvements in generated code for Python + +SWIG-1.3.28 summary: +- More powerful renaming (%rename) capability. +- More user friendly warning handling. +- Add finer control for default constructors and destructors. We discourage + the use of the 'nodefault' option, which disables both constructors and + destructors, leading to possible memory leaks. Use instead 'nodefaultctor' + and/or 'nodefaultdtor'. +- Automatic copy constructor wrapper generation via the 'copyctor' option/feature. +- Better handling of Windows extensions and types. +- Better runtime error reporting. +- Add the %catches directive to catch and dispatch exceptions. +- Add the %naturalvar directive for more 'natural' variable wrapping. +- Better default handling of std::string variables using the %naturalvar directive. +- Add the %allowexcept and %exceptionvar directives to handle exceptions when + accessing a variable. +- Add the %delobject directive to mark methods that act like destructors. +- Add the -fastdispatch option to enable smaller and faster overload dispatch + mechanism. +- Template support for %rename, %feature and %typemap improved. +- Add/doc more debug options, such as -dump_module, -debug_typemaps, etc. +- Unified typemap library (UTL) potentially providing core typemaps for all + scripting languages based on the recently evolving Python typemaps. +- New language module: Common Lisp with CFFI. +- Python, Ruby, Perl and Tcl use the new UTL, many old reported and hidden + errors with typemaps are now fixed. +- Initial Java support for languages using the UTL via GCJ, you can now use + Java libraries in your favorite script language using gcj + swig. +- Tcl support for std::wstring. +- PHP4 module update, many error fixes and actively maintained again. +- Allegrocl support for C++, also enhanced C support. +- Ruby support for bang methods. +- Ruby support for user classes as native exceptions. +- Perl improved dispatching in overloaded functions via the new cast and rank + mechanism. +- Perl improved backward compatibility, 5.004 and later tested and working. +- Python improved backward compatibility, 1.5.2 and later tested and working. +- Python can use the same cast/rank mechanism via the -castmode option. +- Python implicit conversion mechanism similar to C++, via the %implicitconv + directive (replaces and improves the implicit.i library). +- Python threading support added. +- Python STL support improved, iterators are supported and STL containers can + use now the native PyObject type. +- Python many performance options and improvements, try the -O option to test + all of them. Python runtime benchmarks show up to 20 times better performance + compared to 1.3.27 and older versions. +- Python support for 'multi-inheritance' on the python side. +- Python simplified proxy classes, now swig doesn't need to generate the + additional 'ClassPtr' classes. +- Python extended support for smart pointers. +- Python better support for static member variables. +- Python backward compatibility improved, many projects that used to work + only with swig-1.3.21 to swig-1.3.24 are working again with swig-1.3.28 +- Python test-suite is now 'valgrinded' before release, and swig also + reports memory leaks due to missing destructors. +- Minor bug fixes and improvements to the Lua, Ruby, Java, C#, Python, Guile, + Chicken, Tcl and Perl modules. + +SWIG-1.3.27 summary: +- Fix bug in anonymous typedef structures which was leading to strange behaviour + +SWIG-1.3.26 summary: +- New language modules: Lua, CLISP and Common Lisp with UFFI. +- Big overhaul to the PHP module. +- Change to the way 'extern' is handled. +- Minor bug fixes specific to C#, Java, Modula3, Ocaml, Allegro CL, + XML, Lisp s-expressions, Tcl, Ruby and Python modules. +- Other minor improvements and bug fixes. + +SWIG-1.3.25 summary: +- Improved runtime type system. Speed of module loading improved in + modules with lots of types. SWIG_RUNTIME_VERSION has been increased + from 1 to 2, but the API is exactly the same; only internal changes + were made. +- The languages that use the runtime type system now support external + access to the runtime type system. +- Various improvements with typemaps and template handling. +- Fewer warnings in generated code. +- Improved colour documentation. +- Many C# module improvements (exception handling, prevention of early + garbage collection, C# attributes support added, more flexible type + marshalling/asymmetric types.) +- Minor improvements and bug fixes specific to the C#, Java, TCL, Guile, + Chicken, MzScheme, Perl, Php, Python, Ruby and Ocaml modules). +- Various other bug fixes and memory leak fixes. + +SWIG-1.3.24 summary: +- Improved enum handling +- More runtime library options +- More bugs fixes for templates and template default arguments, directors + and other areas. +- Better smart pointer support, including data members, static members + and %extend. + +SWIG-1.3.23 summary: +- Improved support for callbacks +- Python docstring support and better error handling +- C++ default argument support for Java and C# added. +- Improved c++ default argument support for the scripting languages plus + option to use original (compact) default arguments. +- %feature and %ignore/%rename bug fixes and mods - they might need default + arguments specified to maintain compatible behaviour when using the new + default arguments wrapping. +- Runtime library changes: Runtime code can now exist in more than one module + and so need not be compiled into just one module +- Further improved support for templates and namespaces +- Overloaded templated function support added +- More powerful default typemaps (mixed default typemaps) +- Some important %extend and director code bug fixes +- Guile now defaults to using SCM API. The old interface can be obtained by + the -gh option. +- Various minor improvements and bug fixes for C#, Chicken, Guile, Java, + MzScheme, Perl, Python and Ruby +- Improved dependencies generation for constructing Makefiles. + +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 *. +- Initial support for Modula3 and Allegro CL. +- 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, Python, Ruby and XML. + + diff --git a/swig.spec.in b/swig.spec.in index 14d95d22f..0f64235fb 100644 --- a/swig.spec.in +++ b/swig.spec.in @@ -50,7 +50,7 @@ rm -rf ${RPM_BUILD_ROOT} %files %defattr(-,root,root) -%doc ANNOUNCE CHANGES FUTURE INSTALL LICENSE NEW README TODO +%doc ANNOUNCE CHANGES INSTALL LICENSE LICENSE-GPL LICENSE-UNIVERSITIES README RELEASENOTES %doc Doc/* %{_bindir}/* %{prefix}/share/* |