[gdal-dev] About CMake build again

[Mateusz Loskot]

On 30 October 2017 at 23:14, Even Rouault <even.rouault at spatialys.com> wrote:
>
> Trying to sum up my thoughts on this topic and answering to various points
> raised in this discussion thread:
>
> - I believe a relevant question to ask to ourselves would be:
> "imagine that GDAL would come without any build system at all, what is the one that we would add" ?

Assuming multi-platform is the critical requirement, there are no real
altenratives that beat CMake.

> Ok, that's a bit silly to turn the question like that, a more
> realistic one would be
> "imagine you're going to create a software that will rule over the world, for the 20 next years
> and beyond, and should run on all reasonable platforms, which build system would we use?

IMHO, answer to that is:
First, write portable code in build system agnostic way:
- Stick to C/C++ standard libraries as much as possible
- Stick to vanila preprocessor magic to handle C/C++ library
differences and incompatibilities.
- Eliminate or platform-specific generated headers (or keep it small,
one for all)
Then, choose multi-platfor build system and keep build configuration
scripts *small*.

That will make it easy to compile the code with any build system
current user wants to use
or any build system the project will switch over to in future, if necessary.

> If the answer is clearly "cmake", then it is worth examining if there is not a path that
> would lead us to that point.

No, the anwer is not "clearly cmake".
CMake is great because it's multi-platform, it is available virtually
everywhere and easy to install.
CMake is terrible because it did not develop any best practices or
conventions regarding how
a perfect build configuration should be developed with CMake. That
historically led to home grown,
overgrown, bloated piles of CMake scripts specific to projects that
require maintenance on its own.
Even worse, many of those badly written scripts made it into CMake
distribution as FindXXX.cmake
modules, and CMake team did not reject or unify them.
The freedom led to ecosystem of numerous distinct build monsters
governed by specific conventions
based on CMake like ECM from KDE, BCM from Boost, and Borsch fall
sinto similar category, I think.
Naturally, GDAL would grown its own, beause CMake is rubbish :-)

An ideal build configuration scripts should be small, even for a large project.
Here is example of such setup proposed for Boost
https://github.com/ned14/boost-bmv-cmake
There is no pile of custom CMake macros or modules provided and that
is an ideal :)

> Similar question: is it an effort that will make GDAL development a bit
> easier for new contributors?

Perhaps, potentially, may be.
Certainly, CMake makes development friendly for use with modern IDEs.

> A nice side effect could also be the opportunity to drop some cruft that has
> accumulated over years in the current build systems (supporting ancient
> library versions that no longer make sense)

Dropping existing cruft is good.
Replacing cruft with new CMake cruft is bad idea.
Unfortunately, in most cases I've seen that is what happens when a
project migrates to CMake.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net