RFC7: Discontinue use of autotools

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

RFC7: Discontinue use of autotools

Daniel Baston
Hi,

I'd like to propose that we revisit RFC 7 [1], introduced in October 2018, which proposes that we use CMake as the exclusive build system for GEOS.

The CMake configuration was added to GEOS 11 years ago and has been officially supported since release 3.5, over five years ago. The CMake configuration has built up strong community momentum and has attracted contributions from 12 developers. Continuing to maintain the autotools configuration increases the effort for developers to contribute to GEOS. I frequently have to re-submit pull requests to address problems in the autotools build, losing 30-60 minutes of productive time each occurrence.

For reference, the last discussion of this issue on geos-devel was in October 2018 [2]. To my knowledge, the technical issues discussed in that thread have long since been resolved. For example, the autotools-like targets ("make distcheck") discussed in that thread were added by Paul in 2019. I think the remainder of the discussion boils down to build system preference. There are plenty of good reasons for preferring one build system or another, and I don't expect every member of the GEOS community to prefer CMake. 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 systems in order to accommodate those preferences.

Thoughts?

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC7: Discontinue use of autotools

Paul Ramsey


> On Jan 8, 2021, at 9:25 AM, Daniel Baston <[hidden email]> 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 systems in order to accommodate those preferences.

I agree. I can think of only one further technical task, which is ensuring that the outputs of the cmake 'make dist' target are run through to 'make check' in CI. Being able to bundle a release via 'make dist' is a very handy thing and makes 'tag to release automatically' a potential CI target which would also be nice.

P.
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC7: Discontinue use of autotools

Martin Davis-3
In reply to this post by Daniel Baston
Sounds like a great idea to me.  As you say, supporting two build systems is unproductive and buggy.

On Fri, Jan 8, 2021 at 9:25 AM Daniel Baston <[hidden email]> wrote:
Hi,

I'd like to propose that we revisit RFC 7 [1], introduced in October 2018, which proposes that we use CMake as the exclusive build system for GEOS.

The CMake configuration was added to GEOS 11 years ago and has been officially supported since release 3.5, over five years ago. The CMake configuration has built up strong community momentum and has attracted contributions from 12 developers. Continuing to maintain the autotools configuration increases the effort for developers to contribute to GEOS. I frequently have to re-submit pull requests to address problems in the autotools build, losing 30-60 minutes of productive time each occurrence.

For reference, the last discussion of this issue on geos-devel was in October 2018 [2]. To my knowledge, the technical issues discussed in that thread have long since been resolved. For example, the autotools-like targets ("make distcheck") discussed in that thread were added by Paul in 2019. I think the remainder of the discussion boils down to build system preference. There are plenty of good reasons for preferring one build system or another, and I don't expect every member of the GEOS community to prefer CMake. 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 systems in order to accommodate those preferences.

Thoughts?
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC7: Discontinue use of autotools

Regina Obe
In reply to this post by Paul Ramsey
I'm fine with having only cmake if the issue Paul raised below is fixed.
That is what I currently use for building.

> -----Original Message-----
> From: geos-devel [mailto:[hidden email]] On Behalf Of
> Paul Ramsey
> Sent: Friday, January 8, 2021 12:30 PM
> To: GEOS Development List <[hidden email]>
> Subject: Re: [geos-devel] RFC7: Discontinue use of autotools
>
>
>
> > On Jan 8, 2021, at 9:25 AM, Daniel Baston <[hidden email]> 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 systems in order to
> accommodate those preferences.
>
> I agree. I can think of only one further technical task, which is ensuring
that
> the outputs of the cmake 'make dist' target are run through to 'make
check'
> in CI. Being able to bundle a release via 'make dist' is a very handy
thing and
> makes 'tag to release automatically' a potential CI target which would
also be
> nice.
>
> P.
> _______________________________________________
> geos-devel mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/geos-devel

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC7: Discontinue use of autotools

Greg Troxel-2
In reply to this post by Paul Ramsey

Paul Ramsey <[hidden email]> writes:

>> On Jan 8, 2021, at 9:25 AM, Daniel Baston <[hidden email]> 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 systems in order to accommodate those preferences.
>
> I agree. I can think of only one further technical task, which is
> ensuring that the outputs of the cmake 'make dist' target are run
> through to 'make check' in CI. Being able to bundle a release via
> 'make dist' is a very handy thing and makes 'tag to release
> automatically' a potential CI target which would also be nice.
One thing autotools does that many cmake setups don't (but could) is
'make distcheck' which does

  make dist

  unpacks it

  does an objdir build

  runs make check in that

  does so in a way that the just-built libs are used and installed libs
  are ignored

If that already works in cmake, fine, and if not I think that needs
fixing before getting rid of autotools.

The other thing is cross builds, and I have no idea what the state of
that is in the geos cmake build.  Often I have found that build systems
proposed as a replacement for autotools don't do that.
   

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel

signature.asc (199 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC7: Discontinue use of autotools

Roger Bivand
In reply to this post by Daniel Baston
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.

Roger


--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: [hidden email]
https://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Roger Bivand
NHH Norwegian School of Economics, Bergen, Norway
Reply | Threaded
Open this post in threaded view
|

Re: RFC7: Discontinue use of autotools

Paul Ramsey


> On Jan 8, 2021, at 11:25 AM, Roger Bivand <[hidden email]> 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.

tar xvz geos-3.9.0.tar.bz2
cd geos-3.9.0
mkdir _build
cd _build
cmake ..
make
make check
make install

Or from git:

git clone [hidden email]: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: [hidden email]
> https://orcid.org/0000-0003-2392-6140
> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
> _______________________________________________
> geos-devel mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/geos-devel

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC7: Discontinue use of autotools

Roger Bivand
On Fri, 8 Jan 2021, Paul Ramsey wrote:

>
>
>> On Jan 8, 2021, at 11:25 AM, Roger Bivand <[hidden email]> 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.

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

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).

Roger

>
> Or from git:
>
> git clone [hidden email]: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: [hidden email]
>> https://orcid.org/0000-0003-2392-6140
>> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
>> _______________________________________________
>> geos-devel mailing list
>> [hidden email]
>> 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: [hidden email]
https://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Roger Bivand
NHH Norwegian School of Economics, Bergen, Norway
Reply | Threaded
Open this post in threaded view
|

Re: RFC7: Discontinue use of autotools

Paul Ramsey


> On Jan 8, 2021, at 11:59 AM, Roger Bivand <[hidden email]> wrote:
>
> On Fri, 8 Jan 2021, Paul Ramsey wrote:
>
>>
>>
>>> On Jan 8, 2021, at 11:25 AM, Roger Bivand <[hidden email]> 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 [hidden email]: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: [hidden email]
>>> https://orcid.org/0000-0003-2392-6140
>>> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
>>> _______________________________________________
>>> geos-devel mailing list
>>> [hidden email]
>>> 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: [hidden email]
> https://orcid.org/0000-0003-2392-6140
> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC7: Discontinue use of autotools

Sandro Santilli-4
In reply to this post by Greg Troxel-2
On Fri, Jan 08, 2021 at 01:11:58PM -0500, Greg Troxel wrote:

> One thing autotools does that many cmake setups don't (but could) is
> 'make distcheck' which does
>
>   make dist
>
>   unpacks it
>
>   does an objdir build
>
>   runs make check in that
>
>   does so in a way that the just-built libs are used and installed libs
>   are ignored
>
> If that already works in cmake, fine, and if not I think that needs
> fixing before getting rid of autotools.
>
> The other thing is cross builds, and I have no idea what the state of
> that is in the geos cmake build.  Often I have found that build systems
> proposed as a replacement for autotools don't do that.

I suggest proponents do address the points above. We don't want to
loose functionality for being friendly to Windows (isn't this the main
reason why CMake was introduced?)

--strk;
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC7: Discontinue use of autotools

Daniel Baston
I suggest proponents do address the points above.

As I mentioned, Paul added a "make distcheck" in 2019.
I have no knowledge of cross-compiling other than that people do it. The documentation [1] appears to provide some instructions.
 
We don't want to loose functionality for being friendly to Windows (isn't this the main
reason why CMake was introduced?)

I don't know what the motivation was for introducing CMake originally, but I'm not sure it's relevant 11 years later. The reasons I propose using CMake are described in the RFC [2].

Dan



 

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC7: Discontinue use of autotools

Daniel Baston
In reply to this post by Roger Bivand
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 )

I think the root cause for that confusion was GEOS developers primarily using one build system and downstream developers using another.

 Dan

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC7: Discontinue use of autotools

Sandro Santilli-4
In reply to this post by Daniel Baston
On Fri, Jan 08, 2021 at 04:25:29PM -0500, Daniel Baston wrote:
> >
> > I suggest proponents do address the points above.
>
> As I mentioned, Paul added a "make distcheck" in 2019.

I've just tried "make distcheck" from a build/ subdir.
It created a geos-3.10.0dev.tar.bz2 file of 150MB.

The "make dist" command under autotools generates a
geos-3.10.0dev.tar.gz of less than 6MB.

The "make dist-bzip2" command under autotools generates a
geos-3.10.0dev.tar.bz2 of less than 5MB.

Note autotools support all these target formats:

  dist-gzip
  dist-bzip2
  dist-lzip
  dist-xz
  dist-tarZ
  dist-shar
  dist-zip

> I don't know what the motivation was for introducing CMake originally, but
> I'm not sure it's relevant 11 years later.

It's relevant to the extent that _dropping_ cmake would also resolve
the "need to do double work" issue, if it wasn't for Windows.

As per RFC, the reasons you propose to only keep cmake are:

   1. It is used by the majority of active committers
   2. It is the only cross-platform (OS/compiler) build system

This is it list of most recent commit authors (last 200) intersected
with committers with most commit in repository (top 20), in
alphabetical order:

  Daniel Baston
  Even Rouault
  Martin Davis
  Mike Taves
  Paul Ramsey
  Sandro Santilli

I'm pretty sure the majority of the above committers (also)
use autotools, so the first motivation is not enough.

As for cross-platform features, that I recall Windows is the only
platform that we've had reports of build problems (for MingW not
being evidently easy to setup - this Regina can say more about).

I think binary packagers would have the most informed opinion on the
matter as they are the ones that build on multiple-platforms, usually.
We poor developers mostly build for our single development machines,
so I'd listen carefully to what people like Greg Troxel say.

--strk;
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC7: Discontinue use of autotools

Paul Ramsey


> On Jan 8, 2021, at 2:10 PM, Sandro Santilli <[hidden email]> wrote:
>
> I've just tried "make distcheck" from a build/ subdir.
> It created a geos-3.10.0dev.tar.bz2 file of 150MB.
>
> The "make dist" command under autotools generates a
> geos-3.10.0dev.tar.gz of less than 6MB.
>
The source directory you are making dist against is probably full of old autotools build output, since I can build dist against my pristine source directory and get a geos-3.10.0dev.tar.bz2 of 7161398 bytes.
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC7: Discontinue use of autotools

Paul Ramsey
In reply to this post by Sandro Santilli-4


> On Jan 8, 2021, at 2:10 PM, Sandro Santilli <[hidden email]> wrote:
>
> Note autotools support all these target formats:
>
>  dist-gzip
>  dist-bzip2
>  dist-lzip
>  dist-xz
>  dist-tarZ
>  dist-shar
>  dist-zip

This seems of little relevance since we only distribute bz2
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC7: Discontinue use of autotools

Paul Ramsey
In reply to this post by Sandro Santilli-4


> On Jan 8, 2021, at 2:10 PM, Sandro Santilli <[hidden email]> wrote:
>
> As for cross-platform features, that I recall Windows is the only
> platform that we've had reports of build problems (for MingW not
> being evidently easy to setup - this Regina can say more about).

Windows remains a very important target precisely because so many of the downstream projects (QGIS, Shapely, r.sf) have very large Windows user bases. As a PostGIS person I can sniff that nobody uses windows in production (except I'm wrong, and they do) but as a GEOS person, that huge tail of Windows use has to be kept in mind and is really important.
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC7: Discontinue use of autotools

Paul Ramsey
In reply to this post by Sandro Santilli-4


> On Jan 8, 2021, at 2:10 PM, Sandro Santilli <[hidden email]> wrote:
>
> I think binary packagers would have the most informed opinion on the
> matter as they are the ones that build on multiple-platforms, usually.
> We poor developers mostly build for our single development machines,
> so I'd listen carefully to what people like Greg Troxel say.

Greg's amazing, but we have to look beyond the UNIX family to find the majority of our end users.

P.
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC7: Discontinue use of autotools

Daniel Baston
In reply to this post by Sandro Santilli-4
It's relevant to the extent that _dropping_ cmake would also resolve
the "need to do double work" issue, if it wasn't for Windows.

It doesn't resolve the issue, because we'd need to re-introduce NMake. If you're suggesting that we drop Windows, please make that motion separately.

I'm pretty sure the majority of the above committers (also)
use autotools, so the first motivation is not enough.

I am not using autotools with GEOS but can't speak for others.

Dan

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC7: Discontinue use of autotools

Paul Ramsey


> On Jan 8, 2021, at 2:45 PM, Daniel Baston <[hidden email]> wrote:
>
> It's relevant to the extent that _dropping_ cmake would also resolve
> the "need to do double work" issue, if it wasn't for Windows.
>
> It doesn't resolve the issue, because we'd need to re-introduce NMake. If you're suggesting that we drop Windows, please make that motion separately.
>
> I'm pretty sure the majority of the above committers (also)
> use autotools, so the first motivation is not enough.
>
> I am not using autotools with GEOS but can't speak for others.

cmake exclusively except insofar as release/ci force me to use autotools


_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC7: Discontinue use of autotools

Martin Davis-3
In reply to this post by Daniel Baston
On Fri, Jan 8, 2021 at 2:45 PM Daniel Baston <[hidden email]> wrote

I am not using autotools with GEOS but can't speak for others.

CMake for me, unless forced to run autotools.  

It's quite a bit faster in GH CI too (unless autotools builds are doing something additional)

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
12