<div dir="ltr">Hi All,<div><br></div><div>Apologies for top-posting, albeit the thread has stopped for ~month.<br><div class="gmail_extra"><br></div><div class="gmail_extra">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. </div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div>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.</div><div><br></div><div>*Make drivers plugins*</div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Surely I'm not the only person who would love to see this, and CMake porting would be the ideal time to craft this.</div><div><br></div><div>*External projects*</div><div>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.</div><div><br></div><div dir="ltr"><br></div><div dir="ltr">Btw, CMake works very well on macOS and is my preferred build tool, especially when used with Ninja generator.  :^)<br></div><div dir="ltr"><br></div><div dir="ltr">[0] <a href="https://github.com/OSGeo/homebrew-osgeo4mac/tree/master/Formula">https://github.com/OSGeo/homebrew-osgeo4mac/tree/master/Formula</a></div><div dir="ltr">[1] <a href="https://github.com/orfeotoolbox/OTB/tree/develop/SuperBuild">https://github.com/orfeotoolbox/OTB/tree/develop/SuperBuild</a></div><div dir="ltr"><br></div><div>Regards,<br clear="all"><div><div class="gmail_signature"><div dir="ltr"><br>Larry Shaffer<br>Dakota Cartography<br>Black Hills, South Dakota<br>----------------------------------<br>Boundless Desktop and QGIS Support/Development<br>Boundless Spatial - <a href="http://boundlessgeo.com/" target="_blank">http://boundlessgeo.com</a><br><a href="mailto:lshaffer@boundlessgeo.com" target="_blank">lshaffer@boundlessgeo.com</a><br></div></div></div>
</div></div></div>
<br><div class="gmail_quote">On Tue, Oct 31, 2017 at 5:54 AM, Mateusz Loskot <span dir="ltr"><<a href="mailto:mateusz@loskot.net" target="_blank">mateusz@loskot.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 30 October 2017 at 23:14, Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br>
><br>
> Trying to sum up my thoughts on this topic and answering to various points<br>
> raised in this discussion thread:<br>
><br>
> - I believe a relevant question to ask to ourselves would be:<br>
> "imagine that GDAL would come without any build system at all, what is the one that we would add" ?<br>
<br>
</span>Assuming multi-platform is the critical requirement, there are no real<br>
altenratives that beat CMake.<br>
<span class="gmail-"><br>
> Ok, that's a bit silly to turn the question like that, a more<br>
> realistic one would be<br>
> "imagine you're going to create a software that will rule over the world, for the 20 next years<br>
> and beyond, and should run on all reasonable platforms, which build system would we use?<br>
<br>
</span>IMHO, answer to that is:<br>
First, write portable code in build system agnostic way:<br>
- Stick to C/C++ standard libraries as much as possible<br>
- Stick to vanila preprocessor magic to handle C/C++ library<br>
differences and incompatibilities.<br>
- Eliminate or platform-specific generated headers (or keep it small,<br>
one for all)<br>
Then, choose multi-platfor build system and keep build configuration<br>
scripts *small*.<br>
<br>
That will make it easy to compile the code with any build system<br>
current user wants to use<br>
or any build system the project will switch over to in future, if necessary.<br>
<span class="gmail-"><br>
> If the answer is clearly "cmake", then it is worth examining if there is not a path that<br>
> would lead us to that point.<br>
<br>
</span>No, the anwer is not "clearly cmake".<br>
CMake is great because it's multi-platform, it is available virtually<br>
everywhere and easy to install.<br>
CMake is terrible because it did not develop any best practices or<br>
conventions regarding how<br>
a perfect build configuration should be developed with CMake. That<br>
historically led to home grown,<br>
overgrown, bloated piles of CMake scripts specific to projects that<br>
require maintenance on its own.<br>
Even worse, many of those badly written scripts made it into CMake<br>
distribution as FindXXX.cmake<br>
modules, and CMake team did not reject or unify them.<br>
The freedom led to ecosystem of numerous distinct build monsters<br>
governed by specific conventions<br>
based on CMake like ECM from KDE, BCM from Boost, and Borsch fall<br>
sinto similar category, I think.<br>
Naturally, GDAL would grown its own, beause CMake is rubbish :-)<br>
<br>
An ideal build configuration scripts should be small, even for a large project.<br>
Here is example of such setup proposed for Boost<br>
<a href="https://github.com/ned14/boost-bmv-cmake" rel="noreferrer" target="_blank">https://github.com/ned14/<wbr>boost-bmv-cmake</a><br>
There is no pile of custom CMake macros or modules provided and that<br>
is an ideal :)<br>
<span class="gmail-"><br>
> Similar question: is it an effort that will make GDAL development a bit<br>
> easier for new contributors?<br>
<br>
</span>Perhaps, potentially, may be.<br>
Certainly, CMake makes development friendly for use with modern IDEs.<br>
<span class="gmail-"><br>
> A nice side effect could also be the opportunity to drop some cruft that has<br>
> accumulated over years in the current build systems (supporting ancient<br>
> library versions that no longer make sense)<br>
<br>
</span>Dropping existing cruft is good.<br>
Replacing cruft with new CMake cruft is bad idea.<br>
Unfortunately, in most cases I've seen that is what happens when a<br>
project migrates to CMake.<br>
<span class="gmail-im gmail-HOEnZb"><br>
Best regards,<br>
--<br>
Mateusz Loskot, <a href="http://mateusz.loskot.net" rel="noreferrer" target="_blank">http://mateusz.loskot.net</a><br>
</span><div class="gmail-HOEnZb"><div class="gmail-h5">______________________________<wbr>_________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/gdal-dev</a></div></div></blockquote></div><br></div></div></div>