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 <rune...@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 <rune...@gmail.com> wrote: > >> Thanks Even >> >> On Sun, 11 Apr 2021 at 19:17, Even Rouault <even.roua...@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@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
