[gdal-dev] C++11 timeline

[Kurt Schwehr]

Thanks Gred and Andrew!  Those are exactly the kind of comments that help.

Greg,

I have lots of experience packaging GDAL in fink for the mac, but less
elsewhere.  I found this like which implies that pkgsrc is at GDAL 1.11.3.
Are there better links?

- http://pkgsrc.se/geography/gdal-lib
- https://github.com/joyent/pkgsrc/blob/trunk/geography/gdal-lib/Makefile

On Thu, Jan 12, 2017 at 8:57 AM, Greg Troxel <gdt at lexort.com> wrote:

>
> Kurt Schwehr <schwehr at gmail.com> writes:
>
> > Greg,
> >
> > Can you explain the use case as to what keeps you on an older NetBSD but
> > unable to use a branch of a recent GDAL?  e.g. I'm am suggesting that we
> > keep GDAL 2.1 and older to stay with the current requirement of
> supporting
> > C++03.
>
> That is probably ok.  I should point out that I'm coming at this as a
> packager - I look after a number of geo packages in pkgsrc, which
> supports multiple versions of multiple operating systems, causing it to
> run into more portability issues than packages for a particular Linux
> distribution.  (My actual use of GDAL is so far not extensive and I can
> certainly run it on a newer release.)
>
> My concern is really that once there is a GDAL release that needs a
> newer compiler, then some other program will require that version of
> GDAL.  As a packager, I more or less have to decide whether to update
> each program, balancing users getting new stuff and
> stability/portability.
>
> If no other packages start to depend on unreleased GDAL, and the first
> GDAL release requiring C++11 is a ways off, and by then enough other
> things require it that a system not having a C++11 compiler is totally
> non-viable, then this shouldn't cause problems for pkgsrc.
>
> > As for boost, my experiences are that would be far more effort support it
> > on many platforms than getting a working C++11 compiler.  Boost is full
> of
> > really awesome code, but there be dragons and really careful
> consideration
> > should be made before requiring boost for any code that will have to be
> > linked against by other libraries.
>
> OK - thanks for explaining.
>



-- 
--
http://schwehr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170112/f67474a0/attachment.html>