[gdal-dev] CSharp bindings question

Ari Jolma ari.jolma at gmail.com
Tue May 26 02:09:21 PDT 2015


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
>



More information about the gdal-dev mailing list