Kurt,
The Tamas SDKs are not enough as to provide all the dependencies to a GDAL
Win installation. It miss all those dlls (didn't check if the list is
complete) that the VS2015/17 builds now depend on. So if one wants to
distribute a program that depends on GDAL (GMT, in y case) that long list
of dlls must be supplied as well or otherwise tell users that they have to
install a MS distributable package.
Not a killer feature but annoying certainly.
Yes, if one remains at GDAL <= 2.2 this issue does not exist.
I'm not building GDAL against GEOS so didn't know about it C++11
requirement.
Side and non relevant info, 3 weeks ago I was at the Southern Hemisphere.
Joaquim
api-ms-win-core-console-l1-1-0.dll
api-ms-win-core-datetime-l1-1-0.dll
api-ms-win-core-debug-l1-1-0.dll
api-ms-win-core-errorhandling-l1-1-0.dll
api-ms-win-core-file-l1-1-0.dll
api-ms-win-core-file-l1-2-0.dll
api-ms-win-core-file-l2-1-0.dll
api-ms-win-core-handle-l1-1-0.dll
api-ms-win-core-heap-l1-1-0.dll
api-ms-win-core-interlocked-l1-1-0.dll
api-ms-win-core-libraryloader-l1-1-0.dll
api-ms-win-core-localization-l1-2-0.dll
api-ms-win-core-memory-l1-1-0.dll
api-ms-win-core-namedpipe-l1-1-0.dll
api-ms-win-core-processenvironment-l1-1-0.dll
api-ms-win-core-processthreads-l1-1-0.dll
api-ms-win-core-processthreads-l1-1-1.dll
api-ms-win-core-profile-l1-1-0.dll
api-ms-win-core-rtlsupport-l1-1-0.dll
api-ms-win-core-string-l1-1-0.dll
api-ms-win-core-synch-l1-1-0.dll
api-ms-win-core-synch-l1-2-0.dll
api-ms-win-core-sysinfo-l1-1-0.dll
api-ms-win-core-timezone-l1-1-0.dll
api-ms-win-core-util-l1-1-0.dll
api-ms-win-crt-conio-l1-1-0.dll
api-ms-win-crt-convert-l1-1-0.dll
api-ms-win-crt-environment-l1-1-0.dll
api-ms-win-crt-filesystem-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-locale-l1-1-0.dll
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-multibyte-l1-1-0.dll
api-ms-win-crt-private-l1-1-0.dll
api-ms-win-crt-process-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-time-l1-1-0.dll
api-ms-win-crt-utility-l1-1-0.dll
Joaquim,
Please give it another go at explaining what this use case is and the
issues with it. I didn't follow your comments about the need for
VS2013. If users >are on a legacy compiler (w.r.t. to C++11), can they
not be served by the 2.2 branch? How does that use case fair with the
impending GEOS 3.7.0 >requiring a minimum of C++11?
Thanks,
-kurt
P.S. Doesn't really matter, but here is where I upped the version for VS
on Aug 14 after some discussion with Even:
https://trac.osgeo.org/gdal/wiki/rfc68_cplusplus11?action=diff&version=9&old_version=8
On Wed, Sep 6, 2017 at 11:23 AM, Mateusz Loskot <mate...@loskot.net>
wrote:
On 6 September 2017 at 20:18, Joaquim Luis <jl...@ualg.pt> wrote:
On Wed, 06 Sep 2017 18:34:06 +0100, Mateusz Loskot
<mate...@loskot.net> wrote:
On 6 September 2017 at 19:14, Joaquim Luis <jl...@ualg.pt> wrote:
Wait, does this means that VS2013 will no longer be supported?
With respect, Kurt has been asking for comments for very long time.
Yes that's true, but always understood that VS2013 would be the
minimum.
Kurt posted [1] updated RFC 68 three weeks ago.
It would be enough to have a glance to see VS2015.
[1] https://lists.osgeo.org/pipermail/gdal-dev/2017-August/046951.html
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
----
http://schwehr.org
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
