schwehr at gmail.com
Thu Dec 13 16:30:45 PST 2018
Getting people to be willing to drop support for old compilers is really
difficult. Especially without people who can provide strong support for
older branches of all the related code bases. A bunch of discussion went
into the topic for these 2 RFCs...
C++14 isn't that huge of a jump and if there are features that people
really want that are available in libs like abseil, it isn't unreasonable
to port a copy into a private namespace of GEOS and use it until it can be
refactored out when the minimum compiler make the standin irrelevant. e.g.
make_unique is here and could be converted to geos::private::make_unique or
For deprecated, can just start with something simple like ABSL_DEPRECATED.
And drop it when you can.
On Thu, Dec 13, 2018 at 11:34 AM Greg Troxel <gdt at lexort.com> wrote:
> "Regina Obe" <lr at pcorp.us> writes:
> > I think a lot of packaging (for older systems I see) I see is still
> > done on gcc 4.7. Though one can argue that these older systems will
> > not ship newer GEOS, so might not be so much of an issue aside from
> > users who build their own GEOS stuck on old platforms.
> A good point for Linux, but in the non-Linux world (BSD, MacOS, Solaris,
> the rest of the vendor unix tradition) there is usually a notion of
> "base system" and "packages or other stuff". So with have things like
> mv and the compiler in base, and then packages, the idea of wanting to
> build newer packages with a not bleeding edge but not ancient compiler
> (which describes gcc 4.8) is not really that strange.
> geos-devel mailing list
> geos-devel at lists.osgeo.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the geos-devel