On 1/8/21 11:10 PM, Sandro Santilli 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
> I'm pretty sure the majority of the above committers (also)
> use autotools, so the first motivation is not enough.
I'd be fine with a CMake-only build system.
https://travis-ci.org/github/uclouvain/openjpeg is an exemple of cmake used
with cross-compilation targets (mingw compiler with Linux
>
> It's quite a bit faster in GH CI too (unless autotools builds are doing
> something additional)
>
Not just in CI. CMake+ninja is about 2x faster for me locally. Not sure how
much of that is CMake and how much is ninja.
Dan
___
geos-devel mailing
> On Jan 8, 2021, at 2:51 PM, Martin Davis wrote:
>
> On Fri, Jan 8, 2021 at 2:45 PM Daniel Baston 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
On Fri, Jan 8, 2021 at 2:45 PM Daniel Baston 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)
> On Jan 8, 2021, at 2:45 PM, Daniel Baston 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
>
> 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
> On Jan 8, 2021, at 2:10 PM, Sandro Santilli 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
> On Jan 8, 2021, at 2:10 PM, Sandro Santilli 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
> On Jan 8, 2021, at 2:10 PM, Sandro Santilli 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
> On Jan 8, 2021, at 2:10 PM, Sandro Santilli 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
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
>
> 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
>
> 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
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
> On Jan 8, 2021, at 11:59 AM, Roger Bivand wrote:
>
> On Fri, 8 Jan 2021, Paul Ramsey wrote:
>
>>
>>
>>> On Jan 8, 2021, at 11:25 AM, Roger Bivand wrote:
>>>
>>> In so far as geos-config and geos.pc are generated in forms that autotools
>>> can use (R packages use autotools to
On Fri, 8 Jan 2021, Paul Ramsey wrote:
On Jan 8, 2021, at 11:25 AM, Roger Bivand 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
> On Jan 8, 2021, at 11:25 AM, Roger Bivand 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
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
Paul Ramsey writes:
>> On Jan 8, 2021, at 9:25 AM, Daniel Baston 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
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:geos-devel-boun...@lists.osgeo.org] On Behalf Of
> Paul Ramsey
> Sent: Friday, January 8, 2021 12:30 PM
> To: GEOS
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 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
> On Jan 8, 2021, at 9:25 AM, Daniel Baston 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
>
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
24 matches
Mail list logo
