Re: [geos-devel] An Immodest Proposal

We have recently found one such problem pattern. When using preparedgeometry in postgis, we create a GEOS geometry and associated prepared geometry, these are duly malloc'ed, but we store references to them in a palloc'ed struct in a memory pool which lasts for the life of a postgres

Re: [geos-devel] Boost License compatibility

Mateusz Loskot mate...@loskot.net writes: Folks, mloskot, You Are Not A Lawyer! IANAL either; TINLA. However, I'm trying to understand compatibility of the terms of LGPL and Boost License [1]. Typically when people talk about compatibility of licenses, they are asking: If I combine

Re: [geos-devel] Boost License compatibility

Mateusz Loskot mate...@loskot.net writes: The question is like this: Can I copy lines 10-30 from GEOS source file a.cpp to project X which is licensed under the terms of Boost License? If those lines are deemed to be non-trivial - and the rule of them is that 10 or more lines are definitely

Re: [geos-devel] 3.2.0 release ready for download

work that could be avoided; all depending packages need a version change because they only interoperate with one or the other geos version.) From: Greg Troxel g...@netbsd.org Subject: CVS commit: pkgsrc/geography/geos To: pkgsrc-chan...@netbsd.org Date: Mon, 14 Dec 2009 23:31:06 + Reply-To: g

Re: [geos-devel] 3.3.4 Released

Sandro Santilli s...@keybit.net writes: On Mon, Jun 04, 2012 at 04:06:20PM -0400, Greg Troxel wrote: OK, understood about ABI being unstable, and will try to send a patch. It sounds like then that geos considers any direct use or linking of the C++ library to be a bug on the part of the using

Re: [geos-devel] 3.3.4 Released

Sandro Santilli s...@keybit.net writes: On Mon, Jun 04, 2012 at 04:06:20PM -0400, Greg Troxel wrote: Sandro Santilli s...@keybit.net writes: That seems to be a hint that it's better to use the C API, not a warning that the shlib name is unstable. The warning could indeed be extended

Re: [geos-devel] GEOS License and iOS usage

Stefan Klug klug.ste...@gmx.de writes: I'd like to include libspatialite (https://www.gaia-gis.it/fossil/libspatialite/index ) in a proprietary iPhone App. libspatialite depends on GEOS which is licensed under LGPL. Do you mean create a proprietary iPhone app and distribute it outside

Re: [geos-devel] Do we still need/are maintaining AUTHORS - All in favor of #3 please vote say eye

AUTHORS is part of the GNU Coding Standards for package distribution, authors.svn is a service thing. I'm not clear on authors.svn, but in general when migrating from a centralized VCS (e.g., CVS or svn) to a distributed VCS (e.g., git, hg, etc.) one needs an authors file that defines a

Re: [geos-devel] [postgis-devel] GEOS 3.4.0 is out

Sandro Santilli s...@keybit.net writes: The other was a surprisingly large change in the set of installed files, relative to what I expected from reading NEWS. Most of this diff should make sense to people that don't know pkgsrc details; the last line indicates that the new version installs

Re: [geos-devel] [postgis-devel] GEOS 3.4.0 is out

Paragon Corporation l...@pcorp.us writes: Does the missing platform.h cause you problems? If its still broken for you then I guess we'll need to push a 3.4.1 since fixing this would require changing the Makefile.am again Which is technically part of source. Regarding the platform.h issue

Re: [geos-devel] [postgis-devel] GEOS 3.4.1 is out

Here are the differences in installed files from 3.2.8 to 3.4.1. There are a lot of new 'linearref' and 'triangulate', and a few other changes, but the things that do not make sense to me (from reading the NEWS) are: many algorihm/*.h withdrawn geos/platform.h withdrawn new empty

[geos-devel] test failures

With 3.4.1, I ran the tests on NetBSD 6, i386. I got 3 failures. Are these really XFAIL as some test driveres woudl call them, and known bugs and not indicative that anything is worse on my platform than anywhere else? Runner: testrunner created ./tests/ticket/bug527.xml: case1: test1:

[geos-devel] 3.4.1, stray patch from pkgsrc

pkgsrc is carrying the following patch. It strikes me that probably there should be a configure-time feature test instead. $NetBSD: patch-include-geos-platform.h.in,v 1.4 2012/03/12 09:46:06 fhajny Exp $ Fix isnan definition on NetBSD, DragonFly and SunOS platforms. ---

Re: [geos-devel] [postgis-devel] GEOS 3.4.1 is out

Sandro Santilli s...@keybit.net writes: On Sat, Aug 17, 2013 at 09:00:43PM -0400, Greg Troxel wrote: geos/platform.h withdrawn This is unexpected. We discussed this at 3.4.0 release time and was considered a packaging bug, wasn't it ? If it's still in 3.4.1 we need a 3.4.2 ASAP to fix

Re: [geos-devel] test failures

Mike Toews mwto...@gmail.com writes: On 20 August 2013 21:30, Sandro Santilli s...@keybit.net wrote: Could you please open one ? The testsuite succeeds on my Ubuntu 64bit system. Funny, this problem appears to be only on a 32-bit OS, but not 64-bit. Greg, is your NetBSD 32-bit? Issue

Re: [geos-devel] test failures

Sandro Santilli s...@keybit.net writes: Theoretically -ffloat-store is already used when available, is that working for you guys ? My build did use -ffloat-store. So apparently the issue is not about excess precision. I have run paranoia on NetBSD/i386 - with -ffloat-store it passes, and

Re: [geos-devel] GEOS 3.4.2 is out

I was able to package 3.4.2 for pkgsrc without any issues, and it passes 'make check' on NetBSD 5 i386. Thanks for applying patches for the things I reported. pgpQjOLuLGoOD.pgp Description: PGP signature ___ geos-devel mailing list

Re: [geos-devel] Final thoughts on GEOS on iOS

Malcolm Toon malc...@foreflight.com writes: Sounds like we're just not going to be able to use GEOS. That's fine. We certainly have other options at our disposal, it would have just been nice to use GEOS with spatialite as it was intended. I do appreciate the help, however I am a little

Re: [geos-devel] GEOS Usage

Howard Butler how...@hobu.co writes: You make a good point that a BSD-licensed geos equivalent would be useful to those who wish to create proprietary derived works. That this community is hostile to contribution from organizations such as yours is an opportunity. As I read the mail, people

Re: [geos-devel] Ask for help on building static library for GEOS on armv7 armv7s architecture

kissv kissv@gmail.com writes: I have downloaded the GEOS package(version 3.2.2) from the website http://trac.osgeo.org/geos/, but i was failed to build the static library on armv7 armv7s by using the configure and make tool. I think you mean I tried to cross-build geos for arm on an

Re: [geos-devel] Ask for help on building static library for GEOS on armv7 armv7s architecture

Cross building is pretty tricky. I would suggest that you first get a simple program (e.g., a hand-written hello world) to build and run first, and then move on to geos. This looks wrong: configure:3174: checking for armv7-apple-darwin-gcc configure:3204: result: no configure:3214:

Re: [geos-devel] GEOS Usage

Paul Ramsey pram...@cleverelephant.ca writes: To answer my question, reading through the discussion of LGPL linking, it seems like the *theory* is that, with dynamic linking you can *replace* the library underneath the proprietary code with one that conforms to your wishes/desires, thereby

Re: [geos-devel] branch vs trunk

Jeff McKenna jmcke...@gatewaygeomatics.com writes: On second thought, I decided to go with the stable branch (/3.4). Sorry for the noise. It was actually a really good question. My opinion (I maintain the pkgsrc entry) is that you should only package releases, which sounds like your

Re: [geos-devel] Toward 3.5.0 release

Sandro Santilli s...@keybit.net writes: On Tue, Aug 04, 2015 at 08:15:02AM -0400, Paragon Corporation wrote: Did anyone respond to the call-for-testing on geos lists ? What call? People, especially package maintainers don't like testing stuff unless it's in an unchanging tar ball. Uhm, I

[geos-devel] successful make check on NetBSD 6 i386

With geos trunk from svn updated last night, geos built ok and passed make check (with GNU make; I didn't try native make). The only thing I noticed is that after running make check, running it again rebuilt some of the test programs in capi. That's arguably a bug, but not a big deal. Next up

Re: [geos-devel] git-appraise testing

Sandro Santilli writes: > As we move from SVN to GIT (sloowly, I know, sorry for that) > I started looking at options to get peer reviews w/out being > dependent on a git hosting service (like OSGeo's Gogs or > gitlab) and found this: > > https://github.com/google/git-appraise >

[geos-devel] status of C++ API - is it a bug to use it or not?

Long ago, I complained about the C++ library's major version changing on every release, and was told that the C++ API was basically not supposed to be used by other projects and that there was really no plan to keep it stable. Now we have changes in 3.6 that break osm2pgsql, and that's still not

Re: [geos-devel] Ready to switch from SVN to GIT ?

"Regina Obe" writes: > I don't know why it bugs me so much about reliance on GitHub, but it > does. Perhaps because I feel it's a free lunch that may not be so > free in the future And also I don't like that policies may be pushed > down on us that we don't necessarily want and

Re: [geos-devel] [postgis-devel] GEOS C++ API deprecated?

Mateusz Loskot writes: >> It is a problem to have APIs that are not stable, regardless of >> language. Others, once they realize this, will try not to use APIs at >> all :-) > > Greg, I do understand it. I still keep my position (no longer relevant > for the GEOS decision

Re: [geos-devel] [postgis-devel] GEOS C++ API deprecated?

I realize this is basically over now, but as someone who feels like a bit of an instigator, a few comments. Sebastiaan Couwenberg writes: > On 10/01/2017 10:05 PM, Mateusz Loskot wrote: >> On 1 October 2017 at 21:47, Sebastiaan Couwenberg wrote: >>> On

Re: [geos-devel] Thoughts on Backporting the emit warning message to GEOS 3.6 and GEOS 3.5

Sandro Santilli writes: > On Fri, Oct 06, 2017 at 05:03:58PM -0400, Regina Obe wrote: >> I'm only softly proposing this but want to get a feel if anyone has issues >> before we do. >> >> https://git.osgeo.org/gogs/geos/geos/pulls/14 >> >> I would like to back port this pull to

Re: [geos-devel] Alternative licensing for GEOS

James Turner writes: > We would like to know if alternative licensing is available for GEOS, > as the object distribution requirements for the LGPL don’t really make > any sense in iOS applications. The key issue is that the permission granted is intended to be

Re: [geos-devel] GEOS 3.7.0rc1 release

"Regina Obe" writes: > https://download.osgeo.org/geos/geos-3.7.0rc1.tar.bz2 Updating the pkgsrc entry, I notice: +include/geos/algorithm/distance/DiscreteFrechetDistance.h -include/geos/geom/GeometryList.h +include/geos/operation/distance/IndexedFacetDistance.h which is an API change, but

Re: [geos-devel] GEOS 3.7.0rc1 release

Greg Troxel writes: > However, the C++ library seems messed up and I haven't looked into why > yet (will do, but wanted to caution others to look). > > > libs before: > > -rwxr-xr-x 1 root wheel 20427339 Aug 20 08:06 /usr/pkg/lib/libgeos-3.6.2.so > -lrwxr-xr-x 1 root

Re: [geos-devel] GEOS 3.7.0rc1 release

"Regina Obe" writes: > I asked Sebastian the same thing. He said it's needed in configure > script to escape the [] as I recall. Of course :-) I was looking back and forth in so many rules I forgot which it was. But, I figured out what was wrong. This is the version from configure (so no

Re: [geos-devel] GEOS 3.7.0rc1 release

I believe there is a POSIX spec for sed. So the right thing in sed use is to depend on only what POSIX requires. Which could be avoiding sed :-) I can see if I can fix the regexp ; what it's doing isn't that complicated. Can you explain the extra

Re: [geos-devel] GEOS 3.7.0rc1 release

"Regina Obe" writes: >> From: Greg Troxel [mailto:g...@lexort.com] >> Updating the pkgsrc entry, I notice: >> >> +include/geos/algorithm/distance/DiscreteFrechetDistance.h >> -include/geos/geom/GeometryList.h >> +include/geos/operation/distance

[geos-devel] NEWS comments

A few comments about NEWS: I find the style of listing the alpha and rc separately confusing for those who go from 3.6.2 to 3.7.0 (should be almost everyone). So instead of having them separate, I would start a "3.7.0 (not released yet)" section on the branch used fore 3.7 (which I guess

Re: [geos-devel] NEWS comments

Sebastiaan Couwenberg writes: > I don't think it's the job of a packaging system to specify which > compiler features should be used for reverse dependencies. Stuff like > pkg-config was invented for that. The point is to document that a compiler capable of c++11 is required, so that if the

Re: [geos-devel] GEOS 3.7.0rc1 release

Sebastiaan Couwenberg writes: > On 8/21/18 1:25 AM, Greg Troxel wrote: >> >> is malformed. It's the .* production that the ? applies to (present or >> not). >> >> VERSION_RELEASE=`echo "$VERSION" | sed -E >> 's/^([0-9]+\.[0-9]+\.[

Re: [geos-devel] GEOS 3.7.0rc1 release

Jeff McKenna writes: > That was it, manually copying the missing file from svn or git, into > the release package (geos-3.7.0rc1.tar.bz2) allows GEOS to compile > with msvc 2017. It seems better to adjust the cmake stuff not to expect such a file than to put it in the release. signature.asc

Re: [geos-devel] GEOS 3.7.0rc1 release

"Regina Obe" writes: > https://download.osgeo.org/geos/geos-3.7.0rc1.tar.bz2 Regarding https://trac.osgeo.org/geos/ticket/894 I don't see this on NetBSD/7 amd64, which uses gcc 4.8. I did a build on macos 10.11, which uses clang (but a similar Intel processor): Apple LLVM version 8.0.0

Re: [geos-devel] GEOS 3.7.0rc1 release

Not related to the maybe-clang/GeometryFactory test failure, I tried to build on NetBSD/8 evbearmv7hf-el (RPI3, running 32 bit), and got == : tests/xmltester/test-suite.log == # TOTAL: 1 # PASS: 0 # SKIP: 0

Re: [geos-devel] GEOS 3.7.0rc1 release

Sebastiaan Couwenberg writes: >> Sorry, I am not following. I dug into this harder than probably makes >> sense because I wanted to make sure there wasn't a bug in NetBSD's sed, >> in which case I would file a bug report so it is fixed. >> >> I don't see -E in POSIX's sed spec: >> >>

Re: [geos-devel] GEOS 3.7.0rc1 release

Greg Troxel writes: > Not related to the maybe-clang/GeometryFactory test failure, I tried to > build on NetBSD/8 evbearmv7hf-el (RPI3, running 32 bit), and got > > == > : tests/xmltester

Re: [geos-devel] GEOS 3.7.0rc1 release

I tried 3.6.2, and got the following test result. Has anyone run the geos tests on arm under Linux? (I think this issue should definitely not hold up the release.) == : tests/xmltester/test-suite.log == # TOTAL: 1 #

Re: [geos-devel] GEOS 3.7.0rc1 release

My arm issues are likely not a GEOS bug, and definitely not new. Don't hold up on my account.___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] GEOS 3.7.0rc1 release

I have done more testing on the NetBSD/earmv7 issue. Someone else reproduced it, and also with newer gcc on NetbSD-current, compared to gcc 5.5.0 on my system. NetBSD/sparc64, also newer gcc, passed. I rebuilt with -O0 instead of -O2, and then the xmlrunner tests pass. I get a failure to

Re: [geos-devel] GEOS 3.7.0rc1 release

Sebastiaan Couwenberg writes: > On 9/5/18 2:29 AM, Greg Troxel wrote: >> Has anyone run the geos tests on arm under Linux? > > Yes. > > [urls] Thanks, that's helpful. I ran Kahan's paranoia on my system, which passed cleanly.

Re: [geos-devel] RFC7 - Use CMake as build system for GEOS

Paul Ramsey writes: > Or maybe I should attempt to summarize what I recall from the thread that > seem to me to be reasonable functional requests before going cmake-only: > > - make dist generates a distributable tarball > - make check > - make check runs all tests > - make check builds

Re: [geos-devel] RFC7 - Use CMake as build system for GEOS

Sandro Santilli writes: > On Mon, Oct 01, 2018 at 12:38:50PM -0400, Daniel Baston wrote: >> Hi All, >> >> I've posted an RFC to switch to CMake as the exclusive build system for >> GEOS. Some reasoning is in the RFC itself, but it boils down to wasted >> developer and machine effort supporting

Re: [geos-devel] C++ version, documentation and --std flags

Greg Troxel writes: > The problem seems to be that libgeos.la does not specify -lstdc++ as a > dependency_lib, and the capi test is linked with cc, not c++, so that > standard C++ library isn't linked. > > Changing to using c++ instead of cc on that test makes it link, but

Re: [geos-devel] C++ version, documentation and --std flags

Greg Troxel writes: > On the question of how linking with geos_c is supposed to work,things > look good -- the C++ library has a NEEDED elf note for libstdc++, and > the c library calls for the c++ library. Why geos_c calls for libstdc++ > directly I don't understand, but

Re: [geos-devel] RFC7 - Use CMake as build system for GEOS

pkgsrc is using autoconf. I have had far more problems with cmake over time than with autoconf. This is obviously an issue where people disagree. However, two observations where there is probably common ground: I don't understand windows native builds (because I don't use windows), but I

Re: [geos-devel] RFC7 - Use CMake as build system for GEOS

Sebastiaan Couwenberg writes: > On 10/4/18 4:39 AM, Regina Obe wrote: >>> pkgsrc is using autoconf. I have had far more problems with cmake over >>> time than with autoconf. >>> >> >> But you do use CMake for some things right? >> >> I presume Debian and CentOS packagers already use CMake

Re: [geos-devel] RFC7 - Use CMake as build system for GEOS

Sandro Santilli writes: > On Wed, Oct 03, 2018 at 02:41:34PM -0400, Daniel Baston wrote: >> >> Are you asking whether the GEOS test suite can be run against >> a non-installed copy of the library (yes), or are you referring to >> other tests? > > I'm asking if we can have a "make check" rule,

Re: [geos-devel] RFC7 - Use CMake as build system for GEOS

Daniel Baston writes: >> I'm asking if we can have a "make check" rule, generated by CMake, >> that will run the same tests run by current "make check" rule >> generated by autotools and with the same important condition of >> built binaries and libraries _NOT_ moving out of the build tree. >>

[geos-devel] C++ version, documentation and --std flags

I'm seeing test failures in trunk, built with autotools in an objdir with gcc 4.8 on NetBSD 7 amd64. They are obviously C++ build issues, but only happen when building tests. I am not trying to ask others to debug these in this mail. I looked in README.md to find out what version of C++ is

Re: [geos-devel] C++ version, documentation and --std flags

Sandro Santilli writes: > On Thu, Oct 04, 2018 at 09:28:57AM -0400, Greg Troxel wrote: >> I'm seeing test failures in trunk, built with autotools in an objdir >> with gcc 4.8 on NetBSD 7 amd64. They are obviously C++ build issues, >> but only happen when building tests. I

Re: [geos-devel] C++ version, documentation and --std flags

Here's a patch to README.md on git master. It explains the C++11 requirement, gives clearer examples for using obj/build dirs, and limits the direction to run ldconfig to Linux. >From abedec6b2344e2384b5c74ed6307b88231cf7fec Mon Sep 17 00:00:00 2001 From: Greg Troxel Date: Sat, 6 Oct 2018

Re: [geos-devel] C++ version, documentation and --std flags

"Regina Obe" writes: > What error are you getting? When I try to build using autotools, it also > fails too building the tests > > https://trac.osgeo.org/geos/ticket/913 > > I assume your issue is different as on mine looks like it's just > looking for a non-existent file on my system And

Re: [geos-devel] C++14

"Regina Obe" 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

Re: [geos-devel] C++14

Daniel Baston writes: > Paul raised an issue yesterday about how to mark something as "deprecated" > without using the "[[deprecated]]" attribute provided in C++14. > > It made me wonder what others think about using C++14 for GEOS. I see C++14 > as mostly a "bugfix" to C++11, introducing things

Re: [geos-devel] double double

Paul Ramsey writes: > Mats, what ever happened to: > > https://github.com/libgeos/geos/pull/40 > > I'm just coming up against some stuff in the JTS commit log that expects > double double and I see you've done this work already some years ago, but > it's not committed that I can see. JTS changed

Re: [geos-devel] 3.7.1 Release

"Regina Obe" writes: > Which test was that. Might have been the one that was failing on > Clang (FreeBSD and Mac) that I shushed in 3.7.0. > > In which case it's just as well its removed. I don't think it's entirely clear that the test is wrong, vs the code, vs clang. But maybe it's clear to

Re: [geos-devel] pragma once

Paul Ramsey writes: > As I fart around w/ header guards every time I add a new header/class, > I wonder if changing over to #pragma once would be OK with one and > all? GCC has had it 3.4, and clang has always had it, so…? Is that covered by any standards? (Presumably there is some other

Re: [geos-devel] pragma once

Paul Ramsey writes: > "non standard but widely supported" > > https://en.wikipedia.org/wiki/Pragma_once > > Includes MSVC! :) As much as I hate to depart from standards, that does look near universal. ___ geos-devel mailing list

Re: [geos-devel] RFC 9: Restore C++ API as public API

lnkansa writes: > For the second time, this discussion has become very passionate at some > point. That being said, I believe all the package management issues being > used as an excuse are more of an issue for Linux-based systems. Those who > develop Linux-based applications should know better

Re: [geos-devel] spatialite on iOS/Android

Hans-Georg Haberl writes: > I'm a developer working on UWP, Android and iOS apps using the Xamarin > framework and Entity Framework Core. > I'm working on building spatialite for Android, which depends on the geos > library. > As far as I can tell LGPL is problematic for the Android and Apples

Re: [geos-devel] GEOS 3.8.0 RC3

rc3 seems to be in good order from the pkgsrc viewpoint. * a digression about 3.7.3 I updated pkgsrc belatedly from 3.7.1 to 3.7.3 and tests passed on netbsd-8/amd64. There is a C++ ABI break from 3.7.1 to 3.7.3, which was unexpected. Due to libtool adding in dependency libs from the .la file,

Re: [geos-devel] [GEOS] #1015: Update geos-config tool for consistency

"GEOS" writes: > #1015: Update geos-config tool for consistency > ---+-- > Reporter: robe | Owner: geos-devel@… > Type: defect | Status: new > Priority: minor |

Re: [geos-devel] [GEOS] #1015: Update geos-config tool for consistency

Paul Ramsey writes: > Pkg config is wonderous but still far from universal Interesting. As a packager, I see a vast number of things using it, and thus a system where it isn't available as a build dependency would seem very difficult to deal with in general. I would not have suggested it if

Re: [geos-devel] [GEOS] #1015: Update geos-config tool for consistency

Mike Taves writes: > On Wed, 19 Feb 2020 at 03:11, Greg Troxel wrote: >> In searching for the POSIX printf spec, I found this post about escaping >> spaces in a portable manner. >> >> >> https://stackoverflow.com/questions/12162010/posix-sh-equivalent-fo

Re: [geos-devel] [GEOS] #1015: Update geos-config tool for consistency

This seems to explain how to accomodate spaces in pathnames and escaping them, sticking to POSIX https://stackoverflow.com/questions/12162010/posix-sh-equivalent-for-bash-s-printf-q cmake is very much set up to use pkg-config; it has become the normal way by which build systems query how to

Re: [geos-devel] [GEOS] #1015: Update geos-config tool for consistency

"Regina Obe" writes: > Speaking of reverting the last change that started this whole > discussion -- does anyone have thoughts on alternative to printf for > sh? I would like to keep the intent if possible without causing > backward compatibility issues. > > I assume these are the sections that

Re: [geos-devel] [GEOS] #1015: Update geos-config tool for consistency

Sandro Santilli writes: > Few-years-ago dependency could be fine, given GEOS requires C++10 now, > or we could just use quotes and allow for spaces in path names (while > still forbidding quotes and dollars etc. ?) (I realize this is moot with the simple space escaping you just added. Yay!)

Re: [geos-devel] [GEOS] #1015: Update geos-config tool for consistency

Sandro Santilli writes: > Escaping can also be done in POSIX shell, not a big deal. > Let's just understand what we really need. For instance, > how do we want the output of `geos-config --libs` look like, > when there's a space in the path ? > > 0. -L/usr/local silly/lib -lgeos-3.9.0 >

Re: [geos-devel] [GEOS] #1015: Update geos-config tool for consistency

Mike Taves writes: > On Tue, 18 Feb 2020 at 13:20, Greg Troxel wrote: >> "GEOS" writes: >> > **Specify bash, and use printf to escape paths (if needed)** >> > >> > This allows installation with CMake to other directories, such as `/opt/my >

[geos-devel] dependency management and PSC

I was surprised to see a hard dependency on bash land without any prior discussion on the list. I would like to see PSC adopt a notion that any increases in deependencies, especially depending on anything that is not specified by POSIX, require on-list discussion and a PSC vote.

Re: [geos-devel] [GEOS] #1015: Update geos-config tool for consistency

Paul Ramsey writes: > Yeah, and with Apple changing the default shell in OSX, this only gets worse > not better over time… > Could follow the pgsql project and just rewrite the thing (the config > program) in C and be done with it… Or, perhaps generate a pkgconfig file and just get rid of

[geos-devel] --ldflags oddness in geos-config

pkgsrc is carrying this patch. When expanded in our build, this turns into --ldflags) echo -L${exec_prefix}/lib -Wl,-R/usr/pkg/lib ;; It seems clear that the rpath type instructions need to be continued on; without it the build of the program that depends on geos will be wrong.

Re: [geos-devel] --ldflags oddness in geos-config

Greg Troxel writes: > Plus, it seems all the --libs stanzas have -L${exec_prefix}/lib in them, > even though those are lddfags, not libs. Theory: geos considers "libs" to be -L$prefix/lib -lgeos_c and "ldflags" to be extra stuff So in addition to my patch, probabl

Re: [geos-devel] Motion: stop brain damage and move finally to github as primary repository

Sandro Santilli writes: > On Thu, Oct 01, 2020 at 11:03:29PM +0200, Even Rouault wrote: >> Hi, >> >> Github is a proprietary trap, but not being on it as the >> primary repository is just a waste of time and a lost battle. > > The battle is only lost if you don't fight it. > > --strk;

Re: [geos-devel] GEOS 3.9.0 Released

I should add that 3.9.0 when built on NetBSD 9 amd64 with gcc 7.4.0 builds fine and passes make check. signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] GEOS 3.9.0 Released

(I am late in trying this, for no good reason.) I am doing a trial update of pkgsrc/geography/geos to 3.9.0 from 3.8.1. I am seeing a lot of header file withdrawals, and it is not clear to me that they are explained by "new overlay engine" (but also not clear that they are not explained by

Re: [geos-devel] RFC7: Discontinue use of autotools

Paul Ramsey writes: >> On Jan 8, 2021, at 9:25 AM, Daniel Baston wrote: >> >> I think the question we need to resolve is whether, after 11 years >> of working with and 5 years of officially supporting two build >> systems, we need to continue to spend developer effort maintaining >> both

Re: [geos-devel] RFC7: Discontinue use of autotools

Sebastiaan Couwenberg writes: > On 1/10/21 2:44 AM, Daniel Baston wrote: >>> >>> Make the CMake build adhere to CMAKE_INSTALL_LIBDIR so that multiarch >>> keeps working, >> >> >> I created a pull request for this at >> https://github.com/libgeos/geos/pull/380 >> >> Have CMAKE_BUILD_TYPE=None

Re: [geos-devel] GEOS 3.9.0 Released

Daniel Baston writes: >> >> Some headers I see were installed as a facility for C++ library users. >> Nowadays we discourage those users so I don't see any big problem with >> them being removed (like opBuffer.h and io.h) >> > > I think this comment is about

Re: [geos-devel] Backporting geosop?

Martin Davis writes: > I'm thinking about committing back-ported versions of geosop to 3.9, 3.8 > and 3.7. > > Any objections? And any further objections if I don't bother with the > autotools build setup? The pkgsrc packge for geos is at at 3.9.1, which I think is current, and is using

Re: [geos-devel] Backporting geosop?

Martin Davis writes: > Autotools is still supported for versions <= 3.9.x. > > Not being an autotools expert, I was concerned about breaking something. > And since this is an optional tool, it wasn't clear that it would be needed > in packages. However, I can see that might be desirable. So

Re: [geos-devel] The Road to 3.10

Paul Ramsey writes: > One thing worthy of discussion is pushing forward the cmake > dependency. If we pop forward to 3.12 we can fix this issue cleanly by > using OBJECT instead of STATIC linking for our vendored deps. > > https://github.com/libgeos/geos/issues/463 > > 3.12.0 was released in

Re: [geos-devel] cmake detailed comments

Sandro Santilli writes: > What do you mean by "I like how our tests work now" ? How do they work > for you ? Are them guaranteed to be using the *just_built* (rather > than the *installed*) libraries ? I believe I've found a bug in running tests. When one passes in -W,-R/usr/foo/lib to the

Re: [geos-devel] cmake detailed comments

Paul Ramsey writes: > That is the case on all the platforms we've had reported except > Gregs. Tests work against the libraries built in the build directory. I am not aware of a positive report for not Mac (which does all of this stuff totally differently from normal Unix) 3.9 installed

[geos-devel] cmake detailed comments

As this is my first release using cmake I'm reading INSTALL etc. and have a few comments. 0) INSTALL says; mkdir build && cd build && cmake -DCMAKE_BUILD_TYPE=Release .. Setting `CMAKE_BUILD_TYPE` to `Release` is necessary to enable compiler optimizations. but CMakeLists.txt says:

Re: [geos-devel] 3.10.0beta2

Paul Ramsey writes: > I feel like there is an answer somewhere out there that a NetBSD > expert could find and teach us, and I'd rather not bend around the > whole setup of things because of a fairly niche platform issue. People Maybe, and I'm working on that. So far, it doesn't seem like

Re: [geos-devel] 3.10.0beta2

I've been looking into the test failures. My build passes LDFLAGS of -R/usr/pkg/lib, because pkgsrc builds to a prefix that is not part of the default search path. And, while geos does not depend on libraries from pkgsrc, in general packages depend on other packages and need to find their libs

Re: [geos-devel] cmake detailed comments

I am guessing that this script is not doing anything to set RPATH and that FreeBSD puts /usr/local/lib in the default linker path. Which is interesting because people that build things not from ports might get ports libraries linked without asking for that prefix - but that's a system

Re: [geos-devel] cmake detailed comments

Sandro Santilli writes: > On Wed, Oct 13, 2021 at 03:41:30PM -0700, Paul Ramsey wrote: >> Actually searching for "RPATH" here turns up all kinds of knobs if you want >> different things done to rpath >> >> https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html > > Greg might be

Re: [geos-devel] cmake detailed comments

Sandro Santilli writes: > On Wed, Oct 13, 2021 at 12:08:50PM -0400, Greg Troxel wrote: >> >> Sandro Santilli writes: >> >> > What do you mean by "I like how our tests work now" ? How do they work >> > for you ? Are them guaranteed to be using

Re: [geos-devel] cmake detailed comments

Paul Ramsey writes: > I'm running your script now, but just from looking at it, this seems > suspicious... > > cmake .. \ >-DCMAKE_INSTALL_PREFIX=${PREFIX} \ >-DCMAKE_BUILD_RPATH=${LIBDIR} \ >-DCMAKE_INSTALL_RPATH=${LIBDIR} > > My understanding of the "build

  1   2   >