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

[Greg Troxel]

Sandro Santilli <strk at kbt.io> 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, 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 dist" and "make distcheck" and
> of course the other custom ones ("apidoc"/"doxygen"/"pdf",
> "gen-ChangeLog" etc.)

Agreed that these things are necessary.

This is a key part of why there is pushback from people that don't want
to drop autotools in favor of cmake (strk, bas, and me, at least).
cmake's reason for existence is basically supporting native windows
builds, but it is a step backwards on posix platforms, lacking "make
check" (testing not installed files), "make dist", and "make distcheck"
(testing not only not installed files, but an objdir build of the
just-produced distfile).  Perhaps I'm confused and all of those things
are automatically supported somehow.

And it's not clear to me that cmake supports cross builds by default.


Looking at the goes CMakeList, there are options added for gcc, and for
MS, but some of the gcc options belong for clang too (because they
aren't really gcc options).  In configure.ac, flags are added if
supported, without checking for exact compiler type (and thus working
with clang).

Another place to look for simplification is to stop testing for things
that are required by POSIX, unless it's needed to accomodate windows.
An example is stdint.h and the notion of 64-bit integer types.   It's
true that posix doesn't strictly require int64_t and uint64_t, but it
does say that if 64-bit types exist they have to be usable by those
names:
  http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdint.h.html

Another source of complexity in the cmake build seems to be some mac
framework build that's doing things in a special mac-y way instead of
just using mac as posix.  That is not present in the autoconf build.


I tried the cmake build on NetBSD, and it failed early with isnan
issues.  (The autotools build works fine, which is no surprise since
it's been the standard approach and is well debugged.)   So I wonder how
well the cmake build has been tested on other than windows, and it
seems premature to propose removing autotools.