On 26.05.2015 13:53, Tamas Szekeres wrote:
Is that a requirement that the bindings should work well with all SWIG
versions or that the generated wrappers should work just fine?
I don't know about formal policy, There's nothing in
http://trac.osgeo.org/gdal/wiki/rfc8_devguide nor
http://trac.osgeo.org/gdal/wiki/HowToContribute
IMO that's quite much up to the developer(s) of the bindings in question.
Maybe we need a few rules in two above files. I would like to have some
rules, which would help keeping the common interface files free of #if's.
FWIW, I haven't have much problems with different Swig versions with
Perl bindings.
Ari
Formerly I have been thinking that we should support all versions, but
it took large amount of extra efforts to work around all incompatible
changes what SWIG introduces all the time even with the minor
releases. Regarding to SWIG C# the earlier versions produced
definitely wrong code and I had implement quite some generic stuff in
the bindings (for example to work around the early garbage collection
issues). I see some enhancements in the recent versions in this
regard, but I'm not sure if I can completely remove these additions to
get a stable and consistent build.
Tamas
2015-05-26 11:09 GMT+02:00 Ari Jolma <ari.jo...@gmail.com
<mailto:ari.jo...@gmail.com>>:
26.05.2015, 11:38, Even Rouault kirjoitti:
Le mardi 26 mai 2015 10:13:49, Tamas Szekeres a écrit :
Hi Ari,
I haven't tried to compile that with mono for quite a long
time. I'll give
it a try.
However we did not follow the latest changes in the SWIG
implementation
with the bindings, so I'd try with an earlier version (ie.
1.3.39) to
generate the wrappers.
I can confirm that I can compile the CSharp bindings on Linux
with SWIG 1.3.40
(and run the tests), but I get the same error as Ari with SWIG
2.0.X
As far as I know, Java and Python bindings build and run
equaly well with SWIG
1.3.40 or 2.0.X (although there's a Unix makefile hack to have
Python 3.2
compat, conditionnaly applied with SWIG 1.3.40, that is no
longer needed with
SWIG 2.0.4 or later)
Swig 1.3.39 seems questionable. Just look at the download amounts
at sourceforge. 1.3.39 one download and 1.3.40 148 downloads per week.
However, 1.3.39 does *not* put the PVINVOKE() method twice into
the PVINVOKE.cs file.
May be we should consider including the generated
wrappers in gdal instead of let the users to use different
versions with
different results.
It would be good if we could have a common SWIG version that
works for all the
bindings. So currently it seems to be 1.3.40 ?
Regarding putting the generated wrappers in SVN, that's
already what we do for
Python. We could also just include the generated wrappers in
the tarballs.
IMO "users" = people who use ready-made packages. Developers and
packagers should be intelligent enough to use development tools. I
don't like the idea of having generated files in source
repositories. I'm also of the opinion that there should be a
really good reason to use an old version of a common tool. And at
least in my Linux (Mint, Maya - hmm, that seems already pretty
old, I should upgrade) swig 2.0.11 is the current. But that's just
me I guess.
Ari
Even
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
