[geos-devel] 3.10.0beta2

[Greg Troxel]

Paul Ramsey <pramsey at cleverelephant.ca> 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 NetBSD
itself as building into a different prefix with a packaging system, on a
system that expects to use RPATH.

So far it feels to me like the cmake setup is in general unsound; nobody
has been able to point out a mechanism by which it is supposed to do
testing right. I've tried to read about this and it seems both really
complicated and there seems to be a notion that package authors are
supposed to put a lot of complicated stuff in cmakefiles to manage
handling of rpath in lots of different enviroments, instead of this
being something that cmake provides.  I know I've long not been a fan of
cmake (and people on the lists know that too), but people keep telling
me that it's better and that it does everything autoconf does, and I
feel like I often run into regressions.

> can still *use* GEOS pretty easily on NetBSD
> (build/install/forget). The only thing they cannot easily do is run
> tests, which is inconvenient to a very small population, which I
> understand includes you but I hope you'll be OK with us continuing
> down the release path nonetheless.

Formally, I'm not ok with it as I keep hearing that moving from autoconf
to cmake doesn't involve regressions, so I don't think there should be
regressions.

Practically, I have limited energy and won't take it personally.

For now, I'm trying to understand better, as I have to deal with cmake
in a number of projects.   I am going to try to actually read the
cmakefiles....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20211011/5326af51/attachment.sig>