Sandro Santilli <s...@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. _______________________________________________ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel