On Wed, Oct 03, 2018 at 04:23:33PM -0300, Jeff McKenna wrote:
> On 2018-10-03 4:20 PM, Sandro Santilli wrote:
> >
> > If we drop CMake support, they won't bother.
> > How problematic would that be for contributors ?
>
> Can you define what you mean by "that" in your last sentence? What are you
>
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, generated by CMake,
that will run the
On Wed, Oct 03, 2018 at 11:12:18PM -0400, Regina Obe wrote:
> I think we should drop Nmake.
>
> +1
+1
--strk;
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel
> 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.
>
> Also I'd like to have a "make
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 bec
On Thu, Oct 04, 2018 at 08:18:07AM -0400, Daniel Baston wrote:
> > 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 librarie
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, ge
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.
>>
>>
> Proposal of dropping CMake is only driven by raised concerns about
> contributors confusion. I don't care if CMake is kept, as long as
> I (as a contributor) don't have to maintain it.
Thanks for clarifying.
This RFC is about dropping autotools and NMake in favor of CMake,
for the reasons descr
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 neede
On Thu, Oct 04, 2018 at 09:12:38AM -0400, Daniel Baston wrote:
> > Proposal of dropping CMake is only driven by raised concerns about
> > contributors confusion. I don't care if CMake is kept, as long as
> > I (as a contributor) don't have to maintain it.
>
> Thanks for clarifying.
>
> This RFC i
> What you can do to make _me_ use cmake is providing the
> UI and functionality I'm used to
The pieces I'm not sure about are "make dist" and "make distcheck."
The other things you listed are supported. I can try and clarify the docs
at https://trac.osgeo.org/geos/wiki/BuildingOnUnixWithCMake
>
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 am not trying to ask others to
> debug these in this
On 2018-10-04 15:39, Daniel Baston wrote:
What you can do to make _me_ use cmake is providing the
UI and functionality I'm used to
The pieces I'm not sure about are "make dist" and "make distcheck."
autotools and cmake take the opposite approach to creating distribution
archives.
autotools
#931: Add "dist" and "distcheck" targets to CMake
+--
Reporter: dbaston | Owner: geos-devel@…
Type: defect | Status: new
Priority: major | Milestone:
Component: Default |Version: 3.6.2
Severity: Unassig
#931: Add "dist" and "distcheck" targets to CMake
+--
Reporter: dbaston | Owner: dbaston
Type: defect | Status: new
Priority: major | Milestone:
Component: Default | Version: 3.6.2
Severity: Unassigned
> > For the geos package autotools is used because that's the official
> > buildsystem and on Linux superior to CMake. E.g. libtool does the
> > right thing with library versioning.
>
> I have never tried geos cmake, but my broad experience over the years is that
> autotools-based systems almost e
> 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
On Thu, Oct 4, 2018 at 9:58 AM Regina Obe wrote:
> And as Vicky pointed out the CMake setup in GEOS is kinda old and needs to be
> reworked of which Dan did a bit of already.
I think people may be thinking of Mateusz. I haven't done any
work on the GEOS CMake configuration, though I'm intereste
On Wed, Oct 03, 2018 at 10:39:35PM -0400, Regina Obe wrote:
> But for me even when autotools WAS working GEOS compiled way faster
> under CMake than it did under autotools.
I got curious and tested on my system (Ubuntu GNU/Linux 18.04.1 LTS).
For me, autotools build is slightly faster:
build-a
On Thu, Oct 04, 2018 at 04:16:28PM +0200, Sandro Santilli wrote:
> Install/uninstall steps:
>
> build-cmake$ time sudo make install
> real0m1.514s
> user0m0.403s
> sys 0m0.232s
>
> build-autotools$ time sudo make install
> real0m10.302s
> user0m9.643s
> sys
21 matches
Mail list logo
