<div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Hi,</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">We are actively using GDAL on WIndows, Linux and Android to deal with GIS data reading gaps.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Currently we are constrained to using 'gcc 4.7' on Linux, which gives us a lot of C++11 that we currently want to use.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">On Windows we have switched to Visual Studio 2015.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">On Android we will probably use the latest.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">One of the reasons we tend to lag on compilers is due to needing to support customers on older Operating Systems as well as the usual reluctance to upgrade a compiler because of knock-on to system test costs.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">That's not to say don't use new features of C++ or the library, just bear in mind the potential knock on.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">One of the ways we have dealt with this potential knock-on is to use boost to provide many of the missing library features we are using.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">We switch based on cmake tests between boost and the supplied libraries.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">We have found the following very helpful from C++11 (and older):</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><ul><li>shared_ptr<br></li><li>unique_ptr<br></li><li>nullptr<br></li><li>unordered_map<br></li><li>std::thread<br></li><li>std::nothrow for memory allocation<br></li></ul></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">shared_ptr and unique_ptr make the management of allocated memory so much less error prone, so the use internally, even if the API is not changed, would be a bonus.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">To be honest, if needed, we will just update the compilers we use to the minimum required.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Regards</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Damian</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 13 January 2017 at 01:55, Greg Troxel <span dir="ltr"><<a href="mailto:gdt@lexort.com" target="_blank">gdt@lexort.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
Kurt Schwehr <<a href="mailto:schwehr@gmail.com">schwehr@gmail.com</a>> writes:<br>
<br>
> Thanks Gred and Andrew! Those are exactly the kind of comments that help.<br>
><br>
> Greg,<br>
><br>
> I have lots of experience packaging GDAL in fink for the mac, but less<br>
> elsewhere. I found this like which implies that pkgsrc is at GDAL 1.11.3.<br>
> Are there better links?<br>
<br>
</span>Yes, it's behind, for no good reason. I need to update it. I might<br>
have tried and found it non-trivial, but I don't remember clearly.<br>
<br>
> - <a href="http://pkgsrc.se/geography/gdal-lib" rel="noreferrer" target="_blank">http://pkgsrc.se/geography/<wbr>gdal-lib</a><br>
<br>
That's a good link. Canonical http pointer at:<br>
<a href="http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/geography/gdal-lib/" rel="noreferrer" target="_blank">http://cvsweb.netbsd.org/<wbr>bsdweb.cgi/pkgsrc/geography/<wbr>gdal-lib/</a><br>
<br>
Also, this shows build status on a lot of platforms (but a small<br>
fraction of the set pkgsrc is intended to work on):<br>
<br>
<a href="https://bulktracker.appspot.com/pkgresults/geography/gdal-lib" rel="noreferrer" target="_blank">https://bulktracker.appspot.<wbr>com/pkgresults/geography/gdal-<wbr>lib</a><br>
<br>
> - <a href="https://github.com/joyent/pkgsrc/blob/trunk/geography/gdal-lib/Makefile" rel="noreferrer" target="_blank">https://github.com/joyent/<wbr>pkgsrc/blob/trunk/geography/<wbr>gdal-lib/Makefile</a><br>
<br>
That's a soft fork, intending to have a few diffs but not much. The<br>
vast majority of things are the same, especially normal packages like<br>
gdal-lib.<br>
<br>
<br>
<br>
<br>______________________________<wbr>_________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">http://lists.osgeo.org/<wbr>mailman/listinfo/gdal-dev</a><br></blockquote></div><br></div>