[gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption
Now that Tamas has added the msvc2015/2-17SDK's, I'd like to call a vote by the PSC on RFC68: C++11 compilation mode. The draft is here: https://trac.osgeo.org/gdal/wiki/rfc68_cplusplus11 -Kurt > > > Hi Even, > > > > > > The new SDK-s have now been added. > > > > > > Best regards, > > > > > > Tamas > > > > > > 2017-08-29 15:18 GMT+02:00 Tamas Szekeres : > > > > Hi Even, > > > > > > > > Yes, I'm planning to include msvc2015/2017 versions shortly. > > > > > > > > Best regards, > > > > Tamas > > > > > > > > > > > > 2017. aug. 14. dátummal, 19:02 időpontban Even Rouault < > > > > > > > > even.roua...@spatialys.com> írta: > > > > > Hi Tamas, > > > > > > > > > > Unless I'm mistaken your gisinternals.com builds don't include MSVC > > > > > > > > 2015 currently. Right ? Do you have any plans to do so ? Currently the > > > > GDAL > > > > AppVeyor target uses SDKSs from gisinternals to do builds with a > number of > > > > third-party libraries. > > > > > > > > > Even > > > > > > > > > > > This is a call for discussion on RFC68 to set C++11 to be the > minimum > > > > > > > > C++ > > > > > > > > > > language version for GDAL trunk. I've drafted the RFC based on > work by > > > > > > Mateusz. > > > > > > > > > > > > https://trac.osgeo.org/gdal/wiki/rfc68_cplusplus11 > > > > > > > > > > > > There was initial discussions back in January of this year: > > > > > > > > > > > > > https://lists.osgeo.org/pipermail/gdal-dev/2017January/thread.html#45786 > > > > > > > > > > Cheers, > > > > > > -kurt > > > > > > Engineer at Google > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption
On mercredi 6 septembre 2017 09:14:10 CEST Kurt Schwehr wrote: > Now that Tamas has added the msvc2015/2-17SDK's, I'd like to call a vote by > the PSC on RFC68: C++11 compilation mode. > > The draft is here: > > https://trac.osgeo.org/gdal/wiki/rfc68_cplusplus11 +1 Just a comment regarding "Remove continuous build targets that do not support C++11 from Travis-CI and AppVeyor". We'll have to be careful as there are subtle differences in configurations / drivers tested in some of the non C++11 capable configurations that would be good to keep. But that should indeed reduce the number of configurations. Even > > -Kurt > > > > Hi Even, > > > > > > > > > > > > The new SDK-s have now been added. > > > > > > > > > > > > Best regards, > > > > > > > > > > > > Tamas > > > > > > 2017-08-29 15:18 GMT+02:00 Tamas Szekeres : > > > > Hi Even, > > > > > > > > > > > > > > > > Yes, I'm planning to include msvc2015/2017 versions shortly. > > > > > > > > > > > > > > > > Best regards, > > > > > > > > Tamas > > > > > > > > > > > > > > > > > > > > > > > > 2017. aug. 14. dátummal, 19:02 időpontban Even Rouault < > > > > > > > > even.roua...@spatialys.com> írta: > > > > > Hi Tamas, > > > > > > > > > > > > > > > > > > > > Unless I'm mistaken your gisinternals.com builds don't include MSVC > > > > > > > > 2015 currently. Right ? Do you have any plans to do so ? Currently the > > > > > > > > GDAL > > > > > > > > AppVeyor target uses SDKSs from gisinternals to do builds with a > > > > number of > > > > > > third-party libraries. > > > > > > > > > Even > > > > > > > > > > > This is a call for discussion on RFC68 to set C++11 to be the > > > > minimum > > > > > > C++ > > > > > > > > > > language version for GDAL trunk. I've drafted the RFC based on > > > > work by > > > > > > > > Mateusz. > > > > > > > > > > > > > > > > > > > > > > > > https://trac.osgeo.org/gdal/wiki/rfc68_cplusplus11 > > > > > > > > There was initial discussions back in January of this year: > > https://lists.osgeo.org/pipermail/gdal-dev/2017January/thread.html#45786 > > > > > > > > Cheers, > > > > > > > > > > > > -kurt > > > > > > > > > > > > Engineer at Google -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption
On Wed, Sep 6, 2017 at 12:14 PM, Kurt Schwehr wrote: > Now that Tamas has added the msvc2015/2-17SDK's, I'd like to call a vote > by the PSC on RFC68: C++11 compilation mode. > > The draft is here: > > https://trac.osgeo.org/gdal/wiki/rfc68_cplusplus11 > I'm late to the party, but I guess I don't understand a few things in the RFC. In Plan: If c++11 mode is enabled, won't ALL code need to be C++11 compliant, rather than just new code? In Core changes and Potential changes: It's not clear to me how these are related to turning on C++ 11 mode. Are the "Core changes" the NECESSARY changes to support the C++11 standard? Are the "not included" features DISALLOWED in future code, or...? Thanks for the clarification. -- Andrew Bell andrew.bell...@gmail.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption
On 6 September 2017 at 18:58, Andrew Bell wrote: > On Wed, Sep 6, 2017 at 12:14 PM, Kurt Schwehr wrote: >> >> Now that Tamas has added the msvc2015/2-17SDK's, I'd like to call a vote >> by the PSC on RFC68: C++11 compilation mode. >> >> The draft is here: >> >> https://trac.osgeo.org/gdal/wiki/rfc68_cplusplus11 > > > I'm late to the party, but I guess I don't understand a few things in the > RFC. > > In Plan: If c++11 mode is enabled, won't ALL code need to be C++11 > compliant, rather than just new code? Any existing code which does not compile as C++11 will have to be updated. C++11 for new code means, we are now allowed to use C++11 features (eg. you can write range-based loops now). Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption
On mercredi 6 septembre 2017 19:04:34 CEST Mateusz Loskot wrote: > On 6 September 2017 at 18:58, Andrew Bell wrote: > > On Wed, Sep 6, 2017 at 12:14 PM, Kurt Schwehr wrote: > >> Now that Tamas has added the msvc2015/2-17SDK's, I'd like to call a vote > >> by the PSC on RFC68: C++11 compilation mode. > >> > >> The draft is here: > >> https://trac.osgeo.org/gdal/wiki/rfc68_cplusplus11 > > > > I'm late to the party, but I guess I don't understand a few things in the > > RFC. > > > > In Plan: If c++11 mode is enabled, won't ALL code need to be C++11 > > compliant, rather than just new code? > > Any existing code which does not compile as C++11 will have to be updated. This is mostly a theoretical case. We have buildbots that compile in C++11 and ran tests for a couple of years now (and one in C++14). And by default (since GDAL 2.2 I think) ./configure already enables C++11 on all C++11 capable compilers. There are perhaps a few niche drivers that depend on third-party SDKs and that people have not compiled in years, but they might be broken in other aspects, so not much of a concern. -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption
Wait, does this means that VS2013 will no longer be supported? That's awful because I'll have to rebuild all my dependencies and honestly do not understand what compiler dlls must be distributed with the code (with VS2013 I only has to ship in 2 dlls) and the last thing I want is to force users to go previously install the MS distributable file (I maintain the GMR Windows installer). Joaquim Now that Tamas has added the msvc2015/2-17SDK's, I'd like to call a vote by the PSC on RFC68: C++11 compilation mode. The draft is here: https://trac.osgeo.org/gdal/wiki/rfc68_cplusplus11 -Kurt Hi Even, The new SDK-s have now been added. Best regards, Tamas 2017-08-29 15:18 GMT+02:00 Tamas Szekeres : > Hi Even, > > Yes, I'm planning to include msvc2015/2017 versions shortly. > > Best regards, > Tamas > > > 2017. aug. 14. dátummal, 19:02 időpontban Even Rouault < > > even.roua...@spatialys.com> írta: > > Hi Tamas, > > > > Unless I'm mistaken your gisinternals.com builds don't include MSVC > > 2015 currently. Right ? Do you have any plans to do so ? Currently the > GDAL > AppVeyor target uses SDKSs from gisinternals to do builds with a number of > third-party libraries. > > > Even > > > > > This is a call for discussion on RFC68 to set C++11 to be the minimum > > C++ > > > > language version for GDAL trunk. I've drafted the RFC based on work by > > > Mateusz. > > > > > > https://trac.osgeo.org/gdal/wiki/rfc68_cplusplus11 > > > > > > There was initial discussions back in January of this year: > > > > > > https://lists.osgeo.org/pipermail/gdal-dev/2017January/thread.html#45786 > > > > Cheers, > > > -kurt > > > Engineer at Google___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption
On 6 September 2017 at 19:11, Even Rouault wrote: > On mercredi 6 septembre 2017 19:04:34 CEST Mateusz Loskot wrote: >> On 6 September 2017 at 18:58, Andrew Bell wrote: >> > On Wed, Sep 6, 2017 at 12:14 PM, Kurt Schwehr wrote: > >> >> Now that Tamas has added the msvc2015/2-17SDK's, I'd like to call a >> >> vote > >> >> by the PSC on RFC68: C++11 compilation mode. > >> >> > >> >> The draft is here: > >> >> https://trac.osgeo.org/gdal/wiki/rfc68_cplusplus11 > >> > > >> > I'm late to the party, but I guess I don't understand a few things in >> > the > >> > RFC. > >> > > >> > In Plan: If c++11 mode is enabled, won't ALL code need to be C++11 > >> > compliant, rather than just new code? > >> > >> Any existing code which does not compile as C++11 will have to be updated. > > > > This is mostly a theoretical case. We have buildbots that compile in C++11 > and ran tests for a couple of years now (and one in C++14). And by default > (since GDAL 2.2 I think) ./configure already enables C++11 on all C++11 > capable compilers. Yes, indeed. I gave a 'generic' answer. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption
On 6 September 2017 at 19:14, Joaquim Luis wrote: > Wait, does this means that VS2013 will no longer be supported? With respect, Kurt has been asking for comments for very long time. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption
On Wed, 06 Sep 2017 18:34:06 +0100, Mateusz Loskot wrote: On 6 September 2017 at 19:14, Joaquim Luis wrote: Wait, does this means that VS2013 will no longer be supported? With respect, Kurt has been asking for comments for very long time. Best regards, Yes that's true, but always understood that VS2013 would be the minimum. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption
Hi, I'm not a PSC member, but like to note the great work Kurt has done on C++11 compilation mode. I strongly support this RFC. Best regards, Dmitry 06.09.17 19:14, Kurt Schwehr пишет: Now that Tamas has added the msvc2015/2-17SDK's, I'd like to call a vote by the PSC on RFC68: C++11 compilation mode. The draft is here: https://trac.osgeo.org/gdal/wiki/rfc68_cplusplus11 -Kurt Hi Even, The new SDK-s have now been added. Best regards, Tamas 2017-08-29 15:18 GMT+02:00 Tamas Szekeres : Hi Even, Yes, I'm planning to include msvc2015/2017 versions shortly. Best regards, Tamas 2017. aug. 14. dátummal, 19:02 időpontban Even Rouault < even.roua...@spatialys.com> írta: Hi Tamas, Unless I'm mistaken your gisinternals.com builds don't include MSVC 2015 currently. Right ? Do you have any plans to do so ? Currently the GDAL AppVeyor target uses SDKSs from gisinternals to do builds with a number of third-party libraries. Even This is a call for discussion on RFC68 to set C++11 to be the minimum C++ language version for GDAL trunk. I've drafted the RFC based on work by Mateusz. https://trac.osgeo.org/gdal/wiki/rfc68_cplusplus11 There was initial discussions back in January of this year: https://lists.osgeo.org/pipermail/gdal-dev/2017January/thread.html#45786 Cheers, -kurt Engineer at Google ___ 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
Re: [gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption
On 6 September 2017 at 20:18, Joaquim Luis wrote: > On Wed, 06 Sep 2017 18:34:06 +0100, Mateusz Loskot wrote: >> On 6 September 2017 at 19:14, Joaquim Luis 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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption
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 wrote: > On 6 September 2017 at 20:18, Joaquim Luis wrote: > > On Wed, 06 Sep 2017 18:34:06 +0100, Mateusz Loskot > wrote: > >> On 6 September 2017 at 19:14, Joaquim Luis 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
Re: [gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption
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 wrote: On 6 September 2017 at 20:18, Joaquim Luis wrote: On Wed, 06 Sep 2017 18:34:06 +0100, Mateusz Loskot wrote: On 6 September 2017 at 19:14, Joaquim Luis 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
Re: [gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption
On 6 September 2017 at 21:21, Joaquim Luis wrote: > 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 > [...] Those belong to Windows Universal Windows Platform API. Those are NOT required by any C/C++ native classic software developed for Windows using VS2015/2017. Check [2] for details. I suggest you do a test: install Python 3.6.2 or later (built using VS2015) on Windows w/o VS2015/2017 and check what VC++ CRT DLLs it deploys. [1] https://en.wikipedia.org/wiki/Universal_Windows_Platform [2] https://www.visualstudio.com/en-us/productinfo/vs2017-compatibility-vs Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption
I was just about to write something along the lines that follow, but Mateusz looks to have more of an understanding. My best guess was that it is an incomplete install of Windows? e.g. https://support.microsoft.com/en-us/help/2999226/update-for-universal-c-runtime-in-windows I haven't done Windows dev since the late 90s, so it helps to lay out more for me or I get lost. On Wed, Sep 6, 2017 at 12:48 PM, Mateusz Loskot wrote: > On 6 September 2017 at 21:21, Joaquim Luis wrote: > > 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 > > [...] > > Those belong to Windows Universal Windows Platform API. > Those are NOT required by any C/C++ native classic software > developed for Windows using VS2015/2017. > Check [2] for details. > > I suggest you do a test: install Python 3.6.2 or later (built using VS2015) > on Windows w/o VS2015/2017 and check what VC++ CRT DLLs it deploys. > > [1] https://en.wikipedia.org/wiki/Universal_Windows_Platform > [2] https://www.visualstudio.com/en-us/productinfo/vs2017-compatibility-vs > > 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
Re: [gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption
On 6 September 2017 at 21:53, Kurt Schwehr wrote: > I was just about to write something along the lines that follow, but Mateusz > looks to have more of an understanding. > > My best guess was that it is an incomplete install of Windows? e.g. > > https://support.microsoft.com/en-us/help/2999226/update-for-universal-c-runtime-in-windows Universal C Runtime and Universal Windows Platform are two different beasts. Universal C Runtime is part of Windows 10+ system Kurt's link above leads to installer of Universal CRT for older Windows versions. Here is into to Universal CRT https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/ It is all related to the fact that VS2015 and VS2017 are binary compatible. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption
On Wed, 06 Sep 2017 21:22:18 +0100, Mateusz Loskot wrote: On 6 September 2017 at 21:53, Kurt Schwehr wrote: I was just about to write something along the lines that follow, but Mateusz looks to have more of an understanding. My best guess was that it is an incomplete install of Windows? e.g. https://support.microsoft.com/en-us/help/2999226/update-for-universal-c-runtime-in-windows Universal C Runtime and Universal Windows Platform are two different beasts. Universal C Runtime is part of Windows 10+ system Kurt's link above leads to installer of Universal CRT for older Windows versions. Here is into to Universal CRT https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/ It is all related to the fact that VS2015 and VS2017 are binary compatible. Well, this is in the minimum confusing and I may have been mislead by my TortoiseSVN installation that ships those dlls. The link says: "If you build software designed for use on Windows operating systems where the Universal CRT is not guaranteed to be installed (i.e., Windows 8.1 and below), your software will need to depend on the above mentioned Windows Update packages to install the Universal CRT." Which means that below Win10 they are nor guarantied to be installed But I only find those DLLs in my system in (as also mentioned in that link) C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC and C:\Program Files (x86)\Windows Kits\10 as well as under C:\Program Files (x86)\Mozilla Firefox or C:\programs\TortoiseSVN\bin and Dependency Walker shows me that VCRUNTIME140.DLL depend on those dlls ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption
On 7 September 2017 at 01:01, Joaquim Luis wrote: > On Wed, 06 Sep 2017 21:22:18 +0100, Mateusz Loskot wrote: >> On 6 September 2017 at 21:53, Kurt Schwehr wrote: >>> >>> I was just about to write something along the lines that follow, but >>> Mateusz >>> looks to have more of an understanding. >>> >>> My best guess was that it is an incomplete install of Windows? e.g. >>> >>> >>> https://support.microsoft.com/en-us/help/2999226/update-for-universal-c-runtime-in-windows >> >> >> Universal C Runtime and Universal Windows Platform are two different >> beasts. >> Universal C Runtime is part of Windows 10+ system >> Kurt's link above leads to installer of Universal CRT for older >> Windows versions. >> >> Here is into to Universal CRT >> >> https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/ >> >> It is all related to the fact that VS2015 and VS2017 are binary >> compatible. > > > > Well, this is in the minimum confusing and I may have been mislead by my > TortoiseSVN installation that ships those dlls. The link says: > > "If you build software designed for use on Windows operating systems where > the Universal CRT is not guaranteed to be installed (i.e., Windows 8.1 and > below), your software will need to depend on the above mentioned Windows > Update packages to install the Universal CRT." Yes, it is confusing. I also completely ignored the fact that I'm on Windows 10. where the Universal CRT is a system component, and since for others there is system update, I assumed everyone with up-to-date older Windows system has got that too. The [1] says "Microsoft Visual Studio 2015 creates a dependency on the Universal CRT when applications are built by using the Windows 10 Software Development Kit (SDK). " I'm not sure what if software is built w/ VS2015 using Windows SDK 8, for example. The [2] says more on upgrading to the Universal CRT. James McNellis (Microsoft) explains in comments to [3]: "One of the design goals for the Universal CRT was to produce a single CRT that could run on all Windows platforms. This includes ancient Windows platforms like Windows XP and recent Windows platforms like Windows Phone or the Windows for IoT. This is the reason that the numerous APISet forwarders (the api-ms-win-*.dll DLLs) are required: On legacy platforms like Windows XP, we need to depend on kernel32.dll, whereas on “modern” platforms like Windows 10 we need to depend on APISets" I'd dare a suspicion that targetting Windows 8 SDK with VS2015 may not require (some) those forwarders. Finally, James McNellis explains in [3]: "Updated September 11, 2015: App-local deployment of the Universal CRT issupported. To obtain the binaries for app-local deployment, install the Windows Software Development Kit (SDK) for Windows 10. The binaries will be installed to C:\Program Files (x86)\Windows Kits\10\Redist\ucrt. You will need to copy all of the DLLs with your app (note that the set of DLLs are necessary is different on different versions of Windows, so you must include all of the DLLs in order for your program to run on all supported versions of Windows)." AFAIU, Universal CRT must be installed as Windows Update. Then, VCRedist package can be included in your installer from merge modules (.msm). My sincere apologies for confusion. I always upgrade to latest Visual Studio + Windows as soon as they are out, so I've been a bit of an ignorant. [1] https://support.microsoft.com/en-us/help/2999226/update-for-universal-c-runtime-in-windows [2] https://docs.microsoft.com/en-us/cpp/porting/upgrade-your-code-to-the-universal-crt [3] https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/ Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption
On jeudi 7 septembre 2017 07:47:40 CEST Mateusz Loskot wrote: > On 7 September 2017 at 01:01, Joaquim Luis wrote: > > On Wed, 06 Sep 2017 21:22:18 +0100, Mateusz Loskot > > wrote: > >> On 6 September 2017 at 21:53, Kurt Schwehr wrote: > >>> I was just about to write something along the lines that follow, but > >>> Mateusz > >>> looks to have more of an understanding. > >>> > >>> My best guess was that it is an incomplete install of Windows? e.g. > >>> > >>> > >>> https://support.microsoft.com/en-us/help/2999226/update-for-universal-c-> > >>> >>> runtime-in-windows>> > >> Universal C Runtime and Universal Windows Platform are two different > >> beasts. > >> Universal C Runtime is part of Windows 10+ system > >> Kurt's link above leads to installer of Universal CRT for older > >> Windows versions. > >> > >> Here is into to Universal CRT > >> > >> https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-univer > >> sal-crt/ > >> > >> It is all related to the fact that VS2015 and VS2017 are binary > >> compatible. > > > > Well, this is in the minimum confusing and I may have been mislead by my > > TortoiseSVN installation that ships those dlls. The link says: > > > > "If you build software designed for use on Windows operating systems where > > the Universal CRT is not guaranteed to be installed (i.e., Windows 8.1 and > > below), your software will need to depend on the above mentioned Windows > > Update packages to install the Universal CRT." > > Yes, it is confusing. I also completely ignored the fact that I'm on Windows > 10. where the Universal CRT is a system component, and since for others > there is system update, I assumed everyone with up-to-date older Windows > system has got that too. I can give you some feedback regarding this. My Ubuntu 16.04 ship by default with wine 1.6 and I tried newest Tamas GDAL builds for VS2017 and it didn't work because vcruntime140.dll that is provided in the zip requires linking against those api-ms-win-crt-*.dll that weren't included in it. I tried to install with winetricks the vs2015 redistribuable but didn't work because wine was too old, and it suggested to use Wine 2. Which I compiled from source, and then the GDAL builds worked there out of the box (no need to install the vs2015 redistribuable) since this version of Wine provides the api-ms-win-crt-*.dll (their Wine implementation, not the MS binaries themselves) I also see that OSGeo4W that now compiles GDAL & QGIS master against VS2015 has a package for the VS2015 redistribuable: http://download.osgeo.org/osgeo4w/x86_64/release/msvcrt/msvcrt2015/ So I suspect the situation is the following : * ship the api-ms-win-crt-*.dll next to your binaries and that should work everywhere * if not shippig the api-ms-win-crt-*.dll next to your binaries: - Win7: install the VS2015 redistribuable - Win8: Windows update - Win10: works out of the box Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption
On 7 September 2017 at 11:58, Even Rouault wrote: > > I can give you some feedback regarding this. > [...] > So I suspect the situation is the following : > > * ship the api-ms-win-crt-*.dll next to your binaries and that should work > everywhere > * if not shippig the api-ms-win-crt-*.dll next to your binaries: > - Win7: install the VS2015 redistribuable > - Win8: Windows update > - Win10: works out of the box Even, Thanks for the update. It kills it right, I think. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption
Thanks Even and Mateusz for clarifying this. And since more people are probably confused as well I find 16 copies of api-ms-win-crt-runtime-l1-1-0.dll in my machine that has a updated Win10 + VS compilers. Among them, those installed by Firefox TortoiseSVN MikTex VScode OneDrive and others curiously I have none in the Windows directory but looked at another Win 10 computer that has no Compilers installed, and found them only under System32, SysWOW64 and an Windows Avast subdir. Well, the usual Windows mess. In summary, it seams fair to require that Win7 users will need to install the the VS2015 redistribuable while the others should not need to install anything else. Joaquim On jeudi 7 septembre 2017 07:47:40 CEST Mateusz Loskot wrote: On 7 September 2017 at 01:01, Joaquim Luis wrote: > On Wed, 06 Sep 2017 21:22:18 +0100, Mateusz Loskot wrote: >> On 6 September 2017 at 21:53, Kurt Schwehr wrote: >>> I was just about to write something along the lines that follow, but >>> Mateusz >>> looks to have more of an understanding. >>> >>> My best guess was that it is an incomplete install of Windows? e.g. >>> >>> >>> https://support.microsoft.com/en-us/help/2999226/update-for-universal-c- >>> runtime-in-windows>> >> Universal C Runtime and Universal Windows Platform are two different >> beasts. >> Universal C Runtime is part of Windows 10+ system >> Kurt's link above leads to installer of Universal CRT for older >> Windows versions. >> >> Here is into to Universal CRT >> >> https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-univer >> sal-crt/ >> >> It is all related to the fact that VS2015 and VS2017 are binary >> compatible. > > Well, this is in the minimum confusing and I may have been mislead by my > TortoiseSVN installation that ships those dlls. The link says: > > "If you build software designed for use on Windows operating systems where > the Universal CRT is not guaranteed to be installed (i.e., Windows 8.1 and > below), your software will need to depend on the above mentioned Windows > Update packages to install the Universal CRT." Yes, it is confusing. I also completely ignored the fact that I'm on Windows 10. where the Universal CRT is a system component, and since for others there is system update, I assumed everyone with up-to-date older Windows system has got that too. I can give you some feedback regarding this. My Ubuntu 16.04 ship by default with wine 1.6 and I >tried newest Tamas GDAL builds for VS2017 and it didn't work because vcruntime140.dll that is >provided in the zip requires linking against those api-ms-win-crt-*.dll that weren't included in >it. I tried to install with winetricks the vs2015 redistribuable but didn't work because wine was >too old, and it suggested to use Wine 2. Which I compiled from source, and then the GDAL builds >worked there out of the box (no need to install the vs2015 redistribuable) since this version of >Wine provides the api-ms-win-crt-*.dll (their Wine implementation, not the MS binaries themselves) I also see that OSGeo4W that now compiles GDAL & QGIS master against VS2015 has a package for the >VS2015 redistribuable: http://download.osgeo.org/osgeo4w/x86_64/release/msvcrt/msvcrt2015/ So I suspect the situation is the following : * ship the api-ms-win-crt-*.dll next to your binaries and that should work everywhere * if not shippig the api-ms-win-crt-*.dll next to your binaries: - Win7: install the VS2015 redistribuable - Win8: Windows update - Win10: works out of the box Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption
On 9/7/2017 9:59 AM, Joaquim Luis wrote: And since more people are probably confused as well I find 16 copies of api-ms-win-crt-runtime-l1-1-0.dll in my machine that has a updated Win10 + VS compilers. Among them, those installed by Firefox TortoiseSVN MikTex VScode OneDrive and others curiously I have none in the Windows directory but looked at another Win 10 computer that has no Compilers installed, and found them only under System32, SysWOW64 and an Windows Avast subdir. Well, the usual Windows mess. For a while now the Windows dll search order starts with the directory that the app was loaded from. This was in response to the "dll hell" phenomenon in earlier editions that was created when an app overrode a dll version expected by a previously installed app. So, at the expense of extra space, it is now common to distribute the required dlls with an app to control the version the app uses. The OS will not reload a dll if one with the same name is already loaded, so someone who foolishly or maliciously redistributes a misnamed dll can still screw you up. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption
On 7 September 2017 at 17:59, Joaquim Luis wrote: > Thanks Even and Mateusz for clarifying this. > Thanks to your persistence that helped to dig the issue further :-) Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption
On 7 September 2017 at 18:44, David Strip wrote: > > For a while now the Windows dll search order starts with the directory that > the app was loaded from. This was in response to the "dll hell" phenomenon > in earlier editions that was created when an app overrode a dll version > expected by a previously installed app. So, at the expense of extra space, > it is now common to distribute the required dlls with an app to control the > version the app uses. Interestingly, Microsoft initially removed possibility of the app-local deployment for UniversalCRT, as per [1] "The design is not ideal for an app-local deployment mechanism, but support for app-local deployment was not part of the original design." Then, crowd appealed to Microsoft strongly enough that Microsoft later decided to allow it as an option, as per "Updated September 11, 2015" in [1] [1] https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/ Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption
On mercredi 6 septembre 2017 11:46:03 CEST Kurt Schwehr wrote: > 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? FYI, just discovered today that Poppler 0.58 requires C++11 as well. -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption
Kurt Schwehr-2 wrote > Now that Tamas has added the msvc2015/2-17SDK's, I'd like to call a vote > by > the PSC on RFC68: C++11 compilation mode. +1 -Jukka Rahkonen- -- Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption
On 2017-09-08 9:43 AM, jratike80 wrote: Kurt Schwehr-2 wrote Now that Tamas has added the msvc2015/2-17SDK's, I'd like to call a vote by the PSC on RFC68: C++11 compilation mode. MS4W binaries for GDAL based on MSVC 2015 have been out there since almost a year now; although the current stable MS4W is still based on MSVC 2012 (stable MS4W is downloaded 6,000 times per month), I'll be moving stable to MSVC 2015 shortly, as it gives proper support for both PHP7 and Python3 builds. As mentioned already, many other GDAL dependencies are moving to C++11, even the latest MrSID SDK requires this. My opinion: this new GDAL requirement for C++11 can be annoying to packagers, but it is necessary. +1 -jeff -- Jeff McKenna MapServer Consulting and Training Services http://www.gatewaygeomatics.com/ ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption
On 2017-09-06 12:14 PM, Kurt Schwehr wrote: Now that Tamas has added the msvc2015/2-17SDK's, I'd like to call a vote by the PSC on RFC68: C++11 compilation mode. The draft is here: https://trac.osgeo.org/gdal/wiki/rfc68_cplusplus11 -Kurt +0 It's not clear to me that the benefits of the C++11 requirement justify the potential trouble for those who have to support platforms with older compilers. I do care about portability, it was one of the founding principles of the project 20 years ago and I do not think that "stick to GDAL 2.2" is an acceptable answer to the portability question. The fact that other SDKs or apps may have the C++11 requirement is also not a justification in my mind either for a core piece as important as GDAL. That being said, I don't think I will be directly affected by the change, and there seem to be enough contributors who are keen on dealing with this that I do not need to worry about the problems and should not block progress. Daniel -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption
Daniel, > It's not clear to me that the benefits of the C++11 requirement justify > the potential trouble for those who have to support platforms with older > compilers. I can understand your concerns, and I would personnaly have been fine with sticking with oldish C++ as well, but we must also take into account the appealing of the project environment to other developers for its long term viability. > I do care about portability, it was one of the founding > principles of the project 20 years ago and I do not think that "stick to > GDAL 2.2" is an acceptable answer to the portability question. The fact > that other SDKs or apps may have the C++11 requirement is also not a > justification in my mind either for a core piece as important as GDAL. If you look at Linux platforms that have not a default C++11-ready compiler (ie gcc < 4.8) and are still security maintained, I don't think there are that many. In Ubuntu world, 12.04 is no longer security maintained since April or May this year. And 14.04 old-LTS has GCC 4.8 Debian old-old-stable wheezy has gcc 4.7 but will be end-of-life May 2018, so when GDAL trunk will be released. Debian old-stable jessie has gcc 4.9, so it is fine. RHEL/Centos 6 with gcc 4.4 and its super long support cycle is probably the only Linux distro that don't have the requirements out-of-the-box and still be security maintained at the time GDAL trunk is released. Supporting old platforms means also supporting old versions of various dependencies. I do not really see a lot of funding coming for those activities, perhaps because people get it for free in all meaning of the term, like most maintainance tasks. If people really need to have recent GDAL on old platforms, they can use backported toolchains, hire developers to backport the features they need to older branches, etc... Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption
> On Sep 8, 2017, at 3:29 PM, Even Rouault wrote: > > If people really need to have recent GDAL on old platforms, they can use > backported toolchains, hire developers to backport the features they need to > older branches, etc... +1 for C++11 Howard ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption
On Fri, 8 Sep 2017, Even Rouault wrote: If you look at Linux platforms that have not a default C++11-ready compiler (ie gcc < 4.8) and are still security maintained, I don't think there are that many. In Ubuntu world, 12.04 is no longer security maintained since April or May this year. And 14.04 old-LTS has GCC 4.8 Debian old-old-stable wheezy has gcc 4.7 but will be end-of-life May 2018, so when GDAL trunk will be released. Debian old-stable jessie has gcc 4.9, so it is fine. RHEL/Centos 6 with gcc 4.4 and its super long support cycle is probably the only Linux distro that don't have the requirements out-of-the-box and still be security maintained at the time GDAL trunk is released. Red Hat have "Software Collections" with several newer version of gcc (up to 4.9.2 and 5.3.1) that can be installed on RHEL/CentOS 6 alongside the system compilers; these build code which is compatible with the system libraries. C++11 should not be a major problem for RHEL/CentOS 6. -- Andrew C. Aitchison Cambridge, UK and...@aitchison.me.uk ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption
I declare RFC68 passed with the following votes: Even +1 Jukka +1 Daniel +0 Howard +1 Kurt +1 I appreciate all the discussion and the non-PSC folks who weighed in. I will update the RFC and begin staging a pull request targeted for Oct 1 or shortly thereafter. -kurt On Fri, Sep 8, 2017 at 2:49 PM, Howard Butler wrote: > > On Sep 8, 2017, at 3:29 PM, Even Rouault > wrote: > > If people really need to have recent GDAL on old platforms, they can use > backported toolchains, hire developers to backport the features they need > to older branches, etc... > > > +1 for C++11 > > Howard > > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption
I've created this ticket to track the process: https://trac.osgeo.org/gdal/ticket/7066 On Mon, Sep 11, 2017 at 8:39 AM, Kurt Schwehr wrote: > I declare RFC68 passed with the following votes: > > Even +1 > Jukka +1 > Daniel +0 > Howard +1 > Kurt +1 > > I appreciate all the discussion and the non-PSC folks who weighed in. I > will update the RFC and begin staging a pull request targeted for Oct 1 or > shortly thereafter. > > -kurt > > On Fri, Sep 8, 2017 at 2:49 PM, Howard Butler wrote: > >> >> On Sep 8, 2017, at 3:29 PM, Even Rouault >> wrote: >> >> If people really need to have recent GDAL on old platforms, they can use >> backported toolchains, hire developers to backport the features they need >> to older branches, etc... >> >> >> +1 for C++11 >> >> Howard >> >> -- -- http://schwehr.org ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
