[gdal-dev] About CMake build again

[Larry Shaffer]

Hi All,

Apologies for top-posting, albeit the thread has stopped for ~month.

While I have not contributed that much to the GDAL project over the years,
I have build it a LOT (mostly on Win and macOS [0]). Switching to CMake
would be a good future-proof, cross-platform move, even if it is overly
verbose at times.

My concern, like others noted here, is that it will not necessarily be
greatly advantageous over the current build scripts. Unless... such an
endeavor leveraged some of CMake's more useful features, namely ease of
defining inter-library pre- or post-build-time dependencies, and external
projects.

*Make drivers plugins*
One of my biggest frustrations with building (and rebuilding) libgdal comes
from the default opportunistic way it finds and links against external libs
when configuring. Sure driver building can be controlled with options, but
why do I need to do this to build the *base* library? If libgdal was rarely
built and all drivers loaded as drivers, programs like QGIS wouldn't crash
because some obscure driver's lib changed (happens often with Homebrew).
This prompts a required rebuild of libgdal again.

I realize that this will take some extra work, and loading all drivers as
plugins may reduce some performance metric(s). The resulting CMake
configure options, though, could be specific to driver, not library, e.g.
-D GDAL_MRSID=ON would generate that plugin, building only the main libgdal
binary and any other dependent lib or driver plugins (none here) as needed.
Build time would be minimal, with the plugin immediately available for
distribution packaging.

Surely I'm not the only person who would love to see this, and CMake
porting would be the ideal time to craft this.

*External projects*
While Borsch has some awesome features, it currently requires out-of-tree
resources. If building GDAL with all dependencies local, like may be
required for a full static iOS build, is a goal, then the existing CMake
ExternalProject feature can be leveraged. A fine example of this is the
SuperBuild aspect of Orfeo ToolBox [1]. Such a setup could existing in-tree
for GDAL, though there is obvious overhead in maintaining
ExternalProject build scripts for many libs; so, maybe only for a standard
set makes sense.


Btw, CMake works very well on macOS and is my preferred build tool,
especially when used with Ninja generator.  :^)

[0] https://github.com/OSGeo/homebrew-osgeo4mac/tree/master/Formula
[1] https://github.com/orfeotoolbox/OTB/tree/develop/SuperBuild

Regards,

Larry Shaffer
Dakota Cartography
Black Hills, South Dakota
----------------------------------
Boundless Desktop and QGIS Support/Development
Boundless Spatial - http://boundlessgeo.com
lshaffer at boundlessgeo.com

On Tue, Oct 31, 2017 at 5:54 AM, Mateusz Loskot <mateusz at loskot.net> wrote:

> 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
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20171128/e184d31c/attachment-0001.html>