[geos-devel] RFC7: Discontinue use of autotools

[Paul Ramsey]

> On Jan 8, 2021, at 11:59 AM, Roger Bivand <Roger.Bivand at nhh.no> wrote:
> 
> On Fri, 8 Jan 2021, Paul Ramsey wrote:
> 
>> 
>> 
>>> On Jan 8, 2021, at 11:25 AM, Roger Bivand <Roger.Bivand at nhh.no> wrote:
>>> 
>>> In so far as geos-config and geos.pc are generated in forms that autotools can use (R packages use autotools to configure the use of external libraries), the main problem is simply that I don't use Cmake, and have never felt confident when obliged to use it. Unless forced, I really prefer not to have to, and as I retire soon, I think I shouldn't begin life as a pensioner by having to learn enough Cmake to be able to build GEOS (nothing else I build regularly uses Cmake).
>>> 
>>> Probably part of the problem is the ./autogen.sh step, which most other libraries do not impose, however, the RFC does not mention this.
>>> 
>>> My feeling is that my interest in tracking developments in GEOS (on behalf of the R spatial cluster of packages, about 950 at last count) before a release process is triggered will weaken sharply if I have to learn Cmake, used for nothing else.
>>> 
>>> The RFC mentions the preferences of commmitters; this is wrong-headed, because the actually useful feedback comes from those in R/Python/etc. who may be able to find regressions, but who will stop testing before release if building from the repo or from source in general gets harder. Then you risk making releases which cause havoc downstream, because you are making it harder for people like me to build from source.  What the committers prefer will decide this, but it isn't wise.
>> 
> 
> Thanks for responding, but:
> 
>> tar xvz geos-3.9.0.tar.bz2
>> cd geos-3.9.0
>> mkdir _build
>> cd _build
>> cmake ..
>> make
>> make check
>> make install
> 
> I already have a clone of the gitea repo, and can if need be change branches (you may recall the non-announcement of needing --enable_overlayng in https://lists.osgeo.org/pipermail/geos-devel/2020-October/009754.html )
> 
> My beef with Cmake is the interactive verbosity to console (in this case not much, other software has been very verbose), and the fact that every time (for other software) I've tried to use it (on Fedora), it has failed often because it wanted something else installed that I didn't need, and that Cmake wanted just to be pretty. Progress percentages are something that I cannot stand (my choice). Running it now on the current state of the gitea repo, I cannot see the verbatim compiler flags - it tells me things that are no use to me, but does not tell me things (in the make step) that might be useful.

make VERBOSE=1

> Is it claimed that make and make check run faster when using cmake - they seem to, but is the test suite the same?

Yes, it is now the same (sometimes cmake is better, because it's easy to forget to add tests to autotools, and autotools is "opt-in" while cmake is "opt-out".

> Yes, of course I can use cmake if I have to.
> 
> I'll be really happy when the Solaris question gets addressed, though, because 3.7.0 and later do not build on the Solaris Intel platform (different compilers):
> 
> https://www.stats.ox.ac.uk/pub/bdr/Rconfig/r-patched-solaris-x86
> 
> It's not that anyone needs to use Solaris, but the code appears to have stopped liking the Solaris build train from 3.7.0, and maybe some assumption was made that was not explicit? The R community does this kind of thing, pointing out issues in upstream compilers and libraries, because the knowledge may be useful (our Sparc Solaris was very useful before it failed).

Sorry, is this a cmake build issue or a Solaris-geos issue? I can believe we've failed our Solaris friends recently, but frankly it's one of those "pay me" platforms because setting up a build env to work in is such a PITA, and extra more so since OpenSolaris went away. Also (and maybe this is less of a problem now) the fact that Solaris build chains can easily end up being mishmashes of GNU tools and proprietary Solaris ones makes for extra fun problems on that platform.

P.

> 
> Roger
> 
>> 
>> Or from git:
>> 
>> git clone git at github.com:libgeos/geos.git geos-git
>> mkdir geos-build
>> cd geos-build
>> cmake ../geos-git
>> make
>> make check
>> make install
>> 
>> I'm working right now on more comprehensive web docs that I hope will make it easier for people to get started and use GEOS.
>> 
>> P.
>> 
>>> 
>>> Roger
>>> 
>>> 
>>> --
>>> Roger Bivand
>>> Department of Economics, Norwegian School of Economics,
>>> Helleveien 30, N-5045 Bergen, Norway.
>>> voice: +47 55 95 93 55; e-mail: Roger.Bivand at nhh.no
>>> https://orcid.org/0000-0003-2392-6140
>>> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
>>> _______________________________________________
>>> geos-devel mailing list
>>> geos-devel at lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/geos-devel
>> 
>> 
> 
> -- 
> Roger Bivand
> Department of Economics, Norwegian School of Economics,
> Helleveien 30, N-5045 Bergen, Norway.
> voice: +47 55 95 93 55; e-mail: Roger.Bivand at nhh.no
> https://orcid.org/0000-0003-2392-6140
> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en