Newer Swig versions...
hobu at IASTATE.EDU
Sun Jul 16 19:44:38 EDT 2006
I put a guard that tests for SWIG 1.3.29 in map.i, but forgot to
include SWIG 1.3.28 to fix the intarray_setitem misery. SWIG changed
how it renamed those method names (for Python only AFAIK) in 1.3.28.
I did not make this fix in the 4.8 branch, however.
The buildkit has both 1.3.27 and 1.3.29 included, but I have been
using 1.3.27 as the default configuration (there's nothing that
limits you from changing the nmake.opt to point at 1.3.29 though).
I would also note that there are some really scary optimizations that
you can use in SWIG 1.3.29 that at first glance appear useful. I
spent a couple of hours fiddling with them that resulted in using the
current swig command that we've always been using ;)
At 6:07 PM +0200 7/12/06, Tamas Szekeres wrote:
>AFAIK the hobu's buildkit is now capable to use even the 1.3.29, and
>the previous ms4w was compiled using that kit (with 1.2.37 setting).
>The SWIG C# may result in unexpected behaviour when using earlier than 1.3.27.
>It must be noted that the SWIG guys like to issue backward
>uncompatible releases so continuously supporting the newer versions is
>a big deal ;-)
>2006/7/12, Steve Lime <Steve.Lime at dnr.state.mn.us>:
>>There is a 1.3.29 I think.
>>>>> thomas bonfort <thomas.bonfort at GMAIL.COM> 7/12/2006 10:50:03 AM >>>
>>just my 2c
>>latest swig (1.3.28) prevents python mapscript from being properly executed:
>>ImportError: ../../build/lib.linux-i686-2.3/_mapscript.so: undefined symbol:
>>see also http://trac.gispython.org/projects/PCL/ticket/44
>>this is not the case with 1.3.24 (or .27 according to the previous link)
>>On 7/12/06, Daniel Morissette <dmorissette at mapgears.com> wrote:
>>> Steve Lime wrote:
>>> > Hi all: Currently all distributions comming off cvs.gis.umn.edu are
>>> being build with Swig 1.3.21. I'm just wondering what folks think about
>>> moving to the latest versions. Has anyone played with MapScript
>>> the new version?
>>> > Steve
>>> I haven't played with SWIG much lately so I do not have an opinion on
>>> the upgrade, but I think we should generate the 4.8.4 release before
>>> doing the switch just to be safe.
>>> BTW, I will prepare the 4.8.4 source for the release later today and
>>> will let you know when it's ready to package.
>>> Daniel Morissette
More information about the mapserver-dev