Um, - plenty of betas, plenty of rc, - the configure thing is your own addition: fix it to force a nocache, or just drop it, - and we're also re-litigating cmake too (the docs unambiguously provide out-of-tree examples only)? - geosop is not mission critical, it can be patched up in micro releases.
P. > On Oct 18, 2021, at 2:27 PM, Sandro Santilli <s...@kbt.io> wrote: > > On Mon, Oct 18, 2021 at 01:33:52PM -0700, Paul Ramsey wrote: >> Having gone through numerous beta and rc releases, and hearing no >> further screams of agony, I call the vote on releasing 3.10.0. >> >> +1 > > I know I'm late to the party but I'm trying builds on multiple > machines now. > > The fist thing that did strike me was that a new ./configure (cmake) > run did NOT result in proper update of all the configuration, but still > remembered my previous cmake run defines so ended up installing GEOS in > /tmp/geos10 (from the tests I was doing with RUNPATH). > > I tried `make distclean` but such target is not present. > I know, `rm -rf <buildtree>` is the cmake way, and I was lucky > to be able to do that, but if you build in the source tree > that's not something you can do easily. > > Second thing: > > $ geosop help test > terminate called after throwing an instance of 'std::invalid_argument' > what(): stod > Aborted (core dumped) > > I'd rather not install `geosop` than letting it core-dump so easily. > It was ticketed as https://trac.osgeo.org/geos/ticket/1126 and then > retargetted to 3.11 milestone, but really, I think we shouldn't > release with such known behaviour. > > --strk; > _______________________________________________ > geos-devel mailing list > geos-devel@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/geos-devel _______________________________________________ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
