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 <g...@lexort.com> wrote: > > Kurt Schwehr <schw...@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
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev