Brian M Hamlin writes:
> if coderabbit AI makes a complete PR in the future, and a GEOS team
> member approves and merges it, what is the committer attribution? Is
> the "author" of that commit now "coderabbitai" .. are there legal
> implications for the project?
code generated by "AI" is
Paul Ramsey via postgis-devel writes:
>> On Nov 10, 2023, at 3:46 PM, Regina Obe wrote:
>>
>> This isn’t an issue with other projects besides PostGIS that use GEOS?
>> Perhaps related, how much trouble would it be to get PostGIS to use
>> pkgconfig for GEOS. I see that GEOS does ship
Paul Ramsey via geos-devel writes:
> I’m on both sides of the argument now. The best/better practice might
> be to leave the install behaviour as-is and try to coerce PostGIS into
> ensuring the LD_RPATH on postgis.so, and other targets is set to the
> discovered locations of the dylib files in
Sebastiaan Couwenberg writes:
> Warning message:
> In fun(libname, pkgname) :
> rgeos: versions of GEOS runtime 3.12.0beta2-CAPI-1.18.0
> and GEOS at installation 3.11.1-CAPI-1.17.1differ
Also, I found that geoe does not use the just-built library when running
tests, due to inadequate
"Regina Obe" writes:
>> On Thu, Jun 15, 2023 at 6:30 AM Greg Troxel wrote:
>>
>> > Looking at the logs (at end), overall this smells like either a
>> > systematic issue where the floating point on my system is broken, or
>> > there is some sl
I have no clear memory of whether I ever tried to build geos or run
tests on RPI3 before. I have a very very vague memory of having trouble
and never having chased it down. So I am definitely not asking that the
release be held for this!
>
This is of course not a request to hold the release; just a comment on
something that I don't yet understand. I am able to run tests by
installing the just built geos and then running them.
The plot thickens on the meta test issues. I built on RPI3 under
NetBSD; geos had not been previously
Paul Ramsey writes:
>> On Jun 7, 2023, at 5:26 PM, Greg Troxel wrote:
>>
>> If I install the 3.12.0beta1 package, then the tests pass. So there is
>> a bug, but it is that the tests appaprently refer to installed files,
>> rather than being controlled to us
If I install the 3.12.0beta1 package, then the tests pass. So there is
a bug, but it is that the tests appaprently refer to installed files,
rather than being controlled to use only files in the build tree. This
requires alternate rpath processing, etc., and in the autoconf world is
usually
Paul Ramsey writes:
> First tagged release auto built and available at
>
> https://github.com/libgeos/geos/releases/tag/3.12.0beta1
distfile not found at standard release location but I fetched it
manually from github.
With the following changes, the package built. The Makefile is just the
In 3.11.2 vs 3.11.1 I find new files installed
ERROR: The following files are in
/tmp/work/geography/geos/work/.destdir/usr/pkg but not in the PLIST:
ERROR:
/tmp/work/geography/geos/work/.destdir/usr/pkg/include/geos/algorithm/PolygonNodeTopology.h
ERROR:
proj in pkgsrc is behind, but it's coded 'c99 c++11', which means gcc
4.8 is probably ok and 4.9 is formally ok. But, that may not be
accurate.
I think of this as "what will be lost for people that don't have X".
For geos, my impression is that this is needed for postgis, spatialite
gdal, and
Daniel Baston writes:
> advantage for reasons I described in a pull request [2]. I don't see a
> reason not to make the change now, since it should have no effect on the
> number of platforms that can build GEOS. (The only versions of gcc and MSVC
> that can build GEOS also support C++14.
What
Martin Davis writes:
> Our development resource bandwidth, and also downstream pipeline size.
>
> I think we should have a policy of one minor release per year (if needed)
> And (try to) make them somewhat scheduled (which we already do informally,
> to align with PostGIS).
There's a big
Also, test suite passes on NetBSD 9 amd64.
The bug (previously sent in email) where the tests use the installed
version instead of the build tree version remains. But after I
installed it and then built and run tests, they passed.
signature.asc
Description: PGP signature
Paul Ramsey writes:
> 3.11.0beta2 has been out for a week, and no complaints. This is the vote on
> final release of 3.11.0
I didn't get to it because it was pkgsrc's quarterly freeze week. It
builds on NetBSD 9 amd64, and I've included the diff to the set of
installed files, minus noise.
Paul Ramsey writes:
> Well, it's super rare, platformwise so I don't really categorize it as
> "our problem", but it's nice to be clearer. What's the simplest way to
I said smartos but this is almost certainly most if not all solaris.
> even find out if a change fixes this? I'm tempted to
Also, I should point out that we are carrying a patch, which seems like
it can't be related, but:
$NetBSD: patch-util_geosop_cxxopts.hpp,v 1.1 2022/03/27 13:33:21 tnn Exp $
On at least modern SunOS, int8_t is typedef'd to char, so parse_value()
that operates on int8_t& conflicts with the one
pkgsrc is getting ready for quarterly branch, and I noticed geos fails
to build on smartos.
https://us-central.manta.mnx.io/pkgsrc/public/reports/upstream-trunk/20220620.2256/geos-3.10.3/build.log
The issue is sqrt(5) leading to ambiguous overload with long double,
double, float.
"Regina Obe" writes:
> It looks in the directory of the dependent executable first for dependencies
> and then looks in PATH for what it couldn't find in the direct path.
> I use the same trick (except export and $ signs) on Debbie and Berrie (both
> Debian bots) and it works there too just
"Regina Obe" writes:
>> > So my PostGIS is compiled with GEOS 3.9.0, but it should work with
>> > GEOS 3.11.
>>
>> You presumably have swapped out the geos implementation? How?
>>
> [Regina Obe]
> I test PostGIS / PostgreSQL with a PostgreSQL launch script that sets the
> path of all the
"Regina Obe" writes:
> I was always under the assumption that the C-API should be upward compatible
> (only the C++ API is unstable).
yes
> Normally I can do the following:
>
> Compile PostGIS with GEOS say 3.9.0
>
> Launch my PostgreSQL with GEOS 3.9.0
>
> Then launch again with newer GEOS
Paul Ramsey writes:
> Let me know what happens on your system?
The destdir has RPATH of the prefix, and the tests have RPATH of only
the build tree. The tests all pass (which is good, because that's
really what matters as the present discussion is about the test harness,
and not about the
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
Paul Ramsey writes:
> OK, this is coming directly out of https://trac.osgeo.org/geos/ticket/1103
>
> If I go back to using an "OBJECT" library in building ryu, then it
> gets bundled right up into libgeos.a where we want it, and your link
> line is nice and simple again. That implies a minimum
Sandro Santilli writes:
>> So this script could perhaps
>>
>> print out that autoconf has been removed and that one must use cmake
>>
>> print out a hint that "cmake -DCMAKE_INSTALL_PREFIX=/usr/foo" is a
>> replacement for ./configure --prefix=/usr/foo
>>
>> exit with status 1, so
(I don't see a rc1 tag in git.)
I see there's configure in git, that sort of deals. However, I don't
think it really does the right thing for all sorts of args that are
often passed to configure, and as much as I don't enjoy cmake pain, I
think it's better for people running configure
tl;dr:
I've done things the cmake way and the test are still not ok.
The problem is that the test RPATH is being *appended* to the BUILD
RPATH, instead of prepended.
long version:
My build script is:
#!/bin/sh
if [ -d $HOME/bin/ccache ]; then
echo
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
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
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
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
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
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:
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
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
Paul Ramsey writes:
>> On Oct 6, 2021, at 4:21 PM, Greg Troxel wrote:
>>
>> Do you mean that if you
>>
>> have geos 3.9 installed in the system, in some prefix
>>
>> you build 3.10 with that same prefix -- as if you are building an
>> updat
Paul Ramsey writes:
> I found the relevant CMake line, and only the unit tests should be ending
> up with a link dependency to pthreads. So don't declare the library itself
> as having a pthread dependency. (Maybe next release, when we get all jiggy
> with multi-threaded performance work, ha ha
Paul Ramsey writes:
> On Sat, Oct 2, 2021 at 4:07 PM Greg Troxel wrote:
>>
>> > Also, the tests are broken for me. Running make check fails
>> > completely, and I find in the log:
>
> Everything works fine in MacOS, I don't have access to a broken platform
Greg Troxel writes:
> Also, the tests are broken for me. Running make check fails
> completely, and I find in the log:
>
> /tmp/work/geography/geos/work/geos-3.10.0beta2/bin/test_geos_unit: Shared
> object "libgeos.so.3.10.0" not found
>
> I am running tests fr
Greg Troxel writes:
> http://download.osgeo.org/geos/geos-3.10.0beta2.tar.bz2
[This note replaces my briefer and less coherent note from last night.]
I converted my package build to cmake, and it worked better than I
expected, which is great. I did my build under pkgsrc on NetBSD 9
am
Paul Ramsey writes:
> Here it is incorporating Sebs feedback, I'm going to try and be pretty
> aggressive about pushing new packages so there's always something worth
> testing against.
Thanks. From my viewpoint a new tarball every time there's a signficant
fix is good.
>
Paul Ramsey writes:
> That feels... off the reservation for a library and something for the final
> build? Like, not every platform requires that link, I don't think.
My quick reaction is that -lstdc++ seems funny for things that are
compiled as C++, but if there's a link line intended to be
I don't care what the word is, but in my view a release which makes the
massive change of dropping automake can't really be called beta, so I
think we need to view this as more alpha like.
I'll try to get to converting the package to cmake and testing soon, but
it may take until Monday when it
Mike Taves writes:
> On Thu, 30 Sept 2021 at 05:16, Paul Ramsey wrote:
>> So the next step on the road to 3.10 is an interim release. I'd like
>> to go right to beta1. If I don't hear any howls in the next 24-48
>> hours, I will cut that package so we can get our packager friends to
>> take it
"Regina Obe" writes:
> BTW according to Myon, they are planning to release PostgreSQL 14 this
> Thursday (tomorrow) so I think our PostGIS 3.2.0 is going to be a little
> later than PostgreSQL 14 release but hopefully we can coax packagers to
> release it.
>
> That said PostGIS release isn't
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
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
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
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
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
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
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
(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
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;
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
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.
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!)
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
>
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
"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
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
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
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
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.
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" writes:
> #1015: Update geos-config tool for consistency
> ---+--
> Reporter: robe | Owner: geos-devel@…
> Type: defect | Status: new
> Priority: minor |
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,
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
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
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
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
"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
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
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
"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
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
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
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
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
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
"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
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
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.
>>
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,
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
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
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
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
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
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.
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
#
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
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
"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
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
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
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:
>>
>>
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]+\.[
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
1 - 100 of 137 matches
Mail list logo
