<div dir="ltr">I must admit that I needed to do it through conda.<br><br>I am no great fan of NuGet but this is not a "package war" thing. My target platform is Unity and that is mono based and does not use NuGet - so if I am going to have to do some handwork to integrate the package management I would rather do it to conda which has vastly superior cross-platform capabilities.<br><br>But, that aside, let me make a case why this approach is better. This approach only builds the c# bindings and runs these on top of the factory default gdal runtime package from conda on all platforms. This means that the available gdal version is always up to date and the drivers are the default set of drivers. There is a small amount of manual work on the c# package when there is a new version of gdal - in most cases it will be of the order of "run trial compile, look at the result, accept it" in which case the c# package will only be a few days behind the latest gdal release. And it runs across a wider range of platforms - including Mac and Windows.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 12 Apr 2021 at 21:37, Björn Harrtell <<a href="mailto:bjorn.harrtell@gmail.com">bjorn.harrtell@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Interesting. I've as of yet only had success with using what is essentially a fork at <a href="https://github.com/MaxRev-Dev/gdal.netcore" target="_blank">https://github.com/MaxRev-Dev/gdal.netcore</a>. 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.</div><div><br></div><div>/Björn</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den mån 12 apr. 2021 kl 21:48 skrev Paul Harwood <<a href="mailto:runette@gmail.com" target="_blank">runette@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Even et al.<br><br>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.<br><br>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.<div><br></div><div>I don't expect a fast turn around from conda-forge. This package does not exactly fall into one of their normal teams :)<br><br>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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 12 Apr 2021 at 08:59, Paul Harwood <<a href="mailto:runette@gmail.com" target="_blank">runette@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Thanks Even</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 11 Apr 2021 at 19:17, Even Rouault <<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    <p>Paul,</p>
    <p>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</p></div></blockquote><div><br></div><div>Cool. I will do that then.<br><br>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!</div><div><br></div><div>Would that be you?</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
    <p>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 <a href="https://github.com/OSGeo/gdal/pull/3670" target="_blank">https://github.com/OSGeo/gdal/pull/3670</a>.
      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</p></div></blockquote><div><span>It is good to able to see that it works and a working example. I will work with what you have in 3670 </span><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
    <p>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.<br></p></div></blockquote><div><br></div><div> 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.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
  </div>

</blockquote></div></div>
</blockquote></div>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div></div>
</blockquote></div>