[gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption

Kurt Schwehr-2
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:


-Kurt

 

> Hi Even,

>

> The new SDK-s have now been added.

>

> Best regards,

>

> Tamas

>

> 2017-08-29 15:18 GMT+02:00 Tamas Szekeres <[hidden email]>:

> > 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 <

> >

> > [hidden email]> í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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC68: C++11 compilation mode - Call for vote on adoption

Even Rouault-2

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 <[hidden email]>:

> > > > 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 <

> > > >

> > > > [hidden email]> í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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC68: C++11 compilation mode - Call for vote on adoption

Andrew Bell
In reply to this post by Kurt Schwehr-2
On Wed, Sep 6, 2017 at 12:14 PM, Kurt Schwehr <[hidden email]> 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:


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
[hidden email]

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC68: C++11 compilation mode - Call for vote on adoption

Mateusz Loskot
On 6 September 2017 at 18:58, Andrew Bell <[hidden email]> wrote:

> On Wed, Sep 6, 2017 at 12:14 PM, Kurt Schwehr <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC68: C++11 compilation mode - Call for vote on adoption

Even Rouault-2

On mercredi 6 septembre 2017 19:04:34 CEST Mateusz Loskot wrote:

> On 6 September 2017 at 18:58, Andrew Bell <[hidden email]> wrote:

> > On Wed, Sep 6, 2017 at 12:14 PM, Kurt Schwehr <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC68: C++11 compilation mode - Call for vote on adoption

Joaquim Luis
In reply to this post by Kurt Schwehr-2
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:


-Kurt

 

> Hi Even,

>

> The new SDK-s have now been added.

>

> Best regards,

>

> Tamas

>

> 2017-08-29 15:18 GMT+02:00 Tamas Szekeres <[hidden email]>:

> > 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 <

> >

> > [hidden email]> í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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC68: C++11 compilation mode - Call for vote on adoption

Mateusz Loskot
In reply to this post by Even Rouault-2
On 6 September 2017 at 19:11, Even Rouault <[hidden email]> wrote:

> On mercredi 6 septembre 2017 19:04:34 CEST Mateusz Loskot wrote:
>> On 6 September 2017 at 18:58, Andrew Bell <[hidden email]> wrote:
>> > On Wed, Sep 6, 2017 at 12:14 PM, Kurt Schwehr <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC68: C++11 compilation mode - Call for vote on adoption

Mateusz Loskot
In reply to this post by Joaquim Luis
On 6 September 2017 at 19:14, Joaquim Luis <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC68: C++11 compilation mode - Call for vote on adoption

Joaquim Luis
On Wed, 06 Sep 2017 18:34:06 +0100, Mateusz Loskot <[hidden email]>  
wrote:

> On 6 September 2017 at 19:14, Joaquim Luis <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC68: C++11 compilation mode - Call for vote on adoption

Dmitry Baryshnikov-2
In reply to this post by Kurt Schwehr-2

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 [hidden email]:

        
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 <

        

          

        
[hidden email]> í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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC68: C++11 compilation mode - Call for vote on adoption

Mateusz Loskot
In reply to this post by Joaquim Luis
On 6 September 2017 at 20:18, Joaquim Luis <[hidden email]> wrote:
> On Wed, 06 Sep 2017 18:34:06 +0100, Mateusz Loskot <[hidden email]> wrote:
>> On 6 September 2017 at 19:14, Joaquim Luis <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC68: C++11 compilation mode - Call for vote on adoption

Kurt Schwehr-2
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:



On Wed, Sep 6, 2017 at 11:23 AM, Mateusz Loskot <[hidden email]> wrote:
On 6 September 2017 at 20:18, Joaquim Luis <[hidden email]> wrote:
> On Wed, 06 Sep 2017 18:34:06 +0100, Mateusz Loskot <[hidden email]> wrote:
>> On 6 September 2017 at 19:14, Joaquim Luis <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC68: C++11 compilation mode - Call for vote on adoption

Joaquim Luis
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:



On Wed, Sep 6, 2017 at 11:23 AM, Mateusz Loskot <[hidden email]> wrote:
On 6 September 2017 at 20:18, Joaquim Luis <[hidden email]> wrote:
> On Wed, 06 Sep 2017 18:34:06 +0100, Mateusz Loskot <[hidden email]> wrote:
>> On 6 September 2017 at 19:14, Joaquim Luis <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC68: C++11 compilation mode - Call for vote on adoption

Mateusz Loskot
On 6 September 2017 at 21:21, Joaquim Luis <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC68: C++11 compilation mode - Call for vote on adoption

Kurt Schwehr-2
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.


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 <[hidden email]> wrote:
On 6 September 2017 at 21:21, Joaquim Luis <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC68: C++11 compilation mode - Call for vote on adoption

Mateusz Loskot
On 6 September 2017 at 21:53, Kurt Schwehr <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC68: C++11 compilation mode - Call for vote on adoption

Joaquim Luis
On Wed, 06 Sep 2017 21:22:18 +0100, Mateusz Loskot <[hidden email]>  
wrote:

> On 6 September 2017 at 21:53, Kurt Schwehr <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC68: C++11 compilation mode - Call for vote on adoption

Mateusz Loskot
On 7 September 2017 at 01:01, Joaquim Luis <[hidden email]> wrote:

> On Wed, 06 Sep 2017 21:22:18 +0100, Mateusz Loskot <[hidden email]> wrote:
>> On 6 September 2017 at 21:53, Kurt Schwehr <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC68: C++11 compilation mode - Call for vote on adoption

Even Rouault-2

On jeudi 7 septembre 2017 07:47:40 CEST Mateusz Loskot wrote:

> On 7 September 2017 at 01:01, Joaquim Luis <[hidden email]> wrote:

> > On Wed, 06 Sep 2017 21:22:18 +0100, Mateusz Loskot <[hidden email]> wrote:

> >> On 6 September 2017 at 21:53, Kurt Schwehr <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC68: C++11 compilation mode - Call for vote on adoption

Mateusz Loskot
On 7 September 2017 at 11:58, Even Rouault <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
12