[gdal-dev] C# bindings compilation

[Björn Harrtell]

Interesting. I've as of yet only had success with using what is essentially
a fork at https://github.com/MaxRev-Dev/gdal.netcore. I've in turn forked
that to enable additional drivers and made my own nuget packages that are
compatible with Debian 10 + .NET Core 3.1 which was my deployment target
and it works like a charm.

/Björn

Den mån 12 apr. 2021 kl 21:48 skrev Paul Harwood <runette at gmail.com>:

> Even et al.
>
> Just to update - your latest changes as per 3670 have done the trick. I
> can now build C# bindings on top of the GDAL3.2.2 conda distribution on
> Windows, Mac and Linux and have successfully run them in .NET / mono.
>
> I solved the compile time problems with a little judicious adjusting of
> the compile-time environment and now have the basis for a package. I just
> need a few more adjustments to make it more production-grade and then I
> will submit it - particularly around tests and around run-time paths.
>
> I don't expect a fast turn around from conda-forge. This package does not
> exactly fall into one of their normal teams :)
>
> Does anyone else want to volunteer to be on the maintainer list for the
> package? Absolutely no work needed, you just the ability to deprecate if
> the package gets very out of date.
>
> On Mon, 12 Apr 2021 at 08:59, Paul Harwood <runette at gmail.com> wrote:
>
>> Thanks Even
>>
>> On Sun, 11 Apr 2021 at 19:17, Even Rouault <even.rouault at spatialys.com>
>> wrote:
>>
>>> Paul,
>>>
>>> RFCs are only required for substantial changes that affect the
>>> OSGeo/GDAL repository. People who contribute to Conda Forge are free to do
>>> so (hopefully in good faith, that is not defacing too much the GDAL
>>> "brand"). If we decided to retire the C# bindings from OSGeo/GDAL this
>>> should probably go through some motion
>>>
>>
>> Cool. I will do that then.
>>
>> I would prefer if the result is at least semi-official and to have some
>> other people from the community listed as maintainers/owners on the package
>> in case something happens to me. There are too many zombie packages out
>> there already!
>>
>> Would that be you?
>>
>>> Regarding build issues on Linux, I could reproduce that, but was like
>>> "worked half time". I finally realized that you had to run "make" twice
>>> because of oddities in the Makefile dependency rules. And there was the
>>> base swig/SWIGmake.base file generating .cpp files in swig/csharp whereas
>>> swig/csharp/GNUmakefile generated them in swig/csharp/gdal|const|ogr|osr.
>>> I've hopefully addressed and rationalized that in
>>> https://github.com/OSGeo/gdal/pull/3670. At least now on my local
>>> machine (ubuntu 20.04), one a clean swig/csharp, "cd swig/csharp && make &&
>>> make test" works. The error you got was similar to the one I got
>>>
>> It is good to able to see that it works and a working example. I will
>> work with what you have in 3670
>>
>>> Regarding your compilation issues with your current recipee, I'd expect
>>> you to have to rather copy most of the content of swig/include,
>>> swig/include/csharp and swig/csharp in your own repository and adapt them
>>> to a standalone build where you include and link against an installed
>>> prefix of the native libgdal.
>>>
>>
>>  That is sort of where I am heading. I want to avoid having anything
>> between the conda feedstock and the root GDAL repo (unless and until there
>> is any change to the way that the GDAL project manages bindings) for
>> maintenance reasons and to avoid creating more zombies. I.e. there is only
>> one definition of the SWIG objects but I have my own makefiles.
>>
>>> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210412/85b5e5a2/attachment.html>