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

Vicky Vergara vicky at georepublic.de
Wed Oct 3 14:15:18 PDT 2018


On Wed, Oct 3, 2018 at 2:44 PM Regina Obe <lr at pcorp.us> wrote:

> >
> > The current situation is really that CMake is a contributed module and
> the
> > official build tool _is_ autotools. The problem reported in that
> > RFC7 is not well-posed in that it assumes contributors are _required_ to
> > support multiple build systems.
> > Truth is they only need to support autotools,
> [Regina Obe]
> Yes they are required to support multiple build systems without CMake.
> E.g. Lots of people on windows building with Visual Studio use GEOS which
> means we need to support NMake if we don't support CMake.
> Autotools is not supported on native Windows.  Cmake can make VS solution
> files.
>
> Also Autotools hasn't worked for me for a long time even under Mingw64.
> Though in theory if I were energetic enough, I guess I could try to
> troubleshoot it.
>
> > How problematic would that be for contributors ?
> >
> > --strk;
> Extremely problematic if we drop CMake.
>
> What ever you drop will be problematic.

About packagers
if system FOO packager use autotools to build GEOS, and autotools is
dropped then they have to change to Cmake
if system BAR packager use Cmake to build GEOS, and autotools is dropped
then they have to change to autotools

if want to remove X, where X IN (Cmake autotools Nmake) then ask packagers
what they use and ask them also
how difficult is for them to build with Y, where Y IN (Cmake autotools
Nmake) AND X != Y

We already have an answer from Regina, "Autotools is not supported on
native Windows."

About contributors
if contributor A  use autotools to build GEOS, and autotools is droped then
they have to change (& probably learn) to Cmake
if contributor B  use Cmake to build GEOS, and autotools is droped then
they have to change to (& probably learn) autotools

For simple contributions like bug fixes, there is no problem the
contributor has nothing to do with autotools or Cmake or Nmake
if GEOS were using only Autotools then as C++ programmer I focus on C++ and
no need to change autotools or Cmake or Nmake, test it on travis & appveyor
if GEOS were using only Cmake then as C++ programmer I focus on C++ and no
need to change autotools or Cmake or Nmake, test it on travis & appveyor

For more complex contributions like adding a test file.
If the contributor knows Cmake, add the test file, and leave to the
autotools expert & Nmake expert the change so it works on that also
If the contributor knows autotools, add the test file, and leave to the
Cmake expert & Nmake expert the change so it works on that also
if the contributor does not know autotools or Nmake or Cmake, add the test
file, and leave to the Cmake expert & Nmake expert the change so it works
on everything
 - try not to ask the contributor to be experts on autotools and Nmake and
Cmake to make their contribution.
 - I know Cmake, but changes on autotools I do are by imitation and test on
Travis. (personally I refuse to learn autotools just because of GEOS, so
imitation is OK for me)

Current state:
- Cmake right now has issues (not building everything that autotools builds)
- Cmake has to be improved (dbaston has a beautiful CmakeLists file for
GEOS in a branch)

My conclusion is:
- Supporting autotools and Nmake and Cmake means a lot of overhead work for
the experts.
  - So, yes, try to keep to the minimum the building process.
  - NOTE: I am biased to: keep Cmake only & drop autotools and Nmake
- GEOS will get to the majority of the users as a package.
  - Ask packagers what they use and also what they can not use. (Like
Reginas example).
  - if CMake happens to work for windows and linux, why keep Nmake?
  - if CMake happens to work on all systems, why keep autotools?
  - Warn packagers on any decision made: "For v3.100 GEOS will be using
Cmake exclusively."
  - While transition to whatever is decided, don't ask the contributor to
be experts on autotools and Nmake and Cmake to make their contribution.
- If, for example, linux packagers use CMake to build GEOS for linux, then
there is no need to test autotools on linux. (see bellow)
- IMPORTANT: if CMake happens to work on all systems,
  - Do not drop autotools until CMake builds everything
    - It is not building everything, is one of the issues it has now.
  - During transition time
    - keep on things as they are now.

Use dbastons CMakeLists.txt work its cleaner. So maybe instead of v3.100 is
v3.50 when the change happens



> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel



-- 

Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44,
81739 München, Germany

Vicky Vergara
Operations Research

eMail: vicky at georepublic.de
Web: https://georepublic.info

Tel: +49 (089) 4161 7698-1
Fax: +49 (089) 4161 7698-9

Commercial register: Amtsgericht München, HRB 181428
CEO: Daniel Kastl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20181003/5de65fb6/attachment-0001.html>


More information about the geos-devel mailing list