<div dir="ltr">+1 to what Howard said.<div><br></div><div>Two thoughts... (and I'm not saying CMake is any worse than autoconf)</div><div><br></div><div>Alternative build systems:</div><div><br></div><div>I co-maintain (mostly just me) a bazel build of GDAL (including autotest2, expat, geos, hdf4, hdf5, hdfeos, kakadu, libgeotiff, libgif, libpng, libtiff, netcdf, jpeg, proj, sqlite, zlib, and some other stuff).  It's exhausting, but it's critical for my business needs. I'm happy to share parts of it if anyone wants.  bazel has lots of great features.  It scales well with parallelization (> 5K build targets with 10's of thousands of source files), does ci well, lets me query the tree (love the <a href="https://en.wikipedia.org/wiki/Directed_acyclic_graph">DAG</a>), and I get to "live at head".  I've added a few patches to GDAL to make it easier for my parallel universe, but the burden is on me and the other folks in that same space, not the core of GDAL.  bazel isn't about the flexibility that many packagers of GDAL want and sometimes require.</div><div><br></div><div><span style="font-size:12.8px">Make drivers plugins:</span><br></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">You talk about the issues of homebrew and crashing with changes due to other libs:  That's a design tradeoff that homebrew took and why I'm still living in fink for that kind of world (bias: I have fink commit access).  A massively plugin world is going to make things even more messy for folks would do actually make sure that requirements are met.  In fink, we try (yeah, it's hard) to force / check ABI compatibility so that you get those types of issues less often.  But that has little to do with the build system.  I worry that more plugs means that end users will have more targets for disaster and packagers have more nodes to worry about.  I suggest watching <a href="https://www.youtube.com/watch?v=tISy7EJQPzI">CppCon 2017: Titus Winters “C++ as a "Live at Head" Language”</a> and thinking hard about the ABI issues he discusses.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I did separate out most of port/ into a separate library in my bazel world to speed up and reduce the footprint of </span><a href="https://github.com/schwehr/gdal-autotest2/tree/master/cpp/port" style="font-size:12.8px">some autotest2 tests</a><span style="font-size:12.8px">.  It would be nice to be able to layer more.  e.g.  I'd love to have a GDALCoreRegister and GDALAllRegister, where core was the minimum set of drivers and GDALAllRegister lived in a separate lib with the rest of the drivers.  But plugins?  Can homebrew have a binary cache like fink/macports?  Or does the design preclude that?</span></div><div><span style="font-size:12.8px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 29, 2017 at 9:47 AM, Howard Butler <span dir="ltr"><<a href="mailto:howard@hobu.co" target="_blank">howard@hobu.co</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Larry,<br>
<br>
I agree that CMake brings some nice and useful features to the table. We<br>
use it for PDAL, but we started out with CMake so there was no migration<br>
that needed to be made.<br>
<br>
CMake for GDAL is a project sustainment issue much more than a<br>
technology switch and a patch. A person or a group of persons needs to<br>
step forward to provide the patches that implement CMake support, and<br>
then that group needs to stick around and keep it up in parallel to the<br>
existing build systems for a while (three major releases?) as all of the<br>
issues with it are identified and resolved. It would be a slog. That<br>
group has to want it bad to bring it over the finish line.<br>
<br>
That effort would have to compete against doing nothing, which every<br>
packaging system that packages GDAL has already plumbed and stitched<br>
around to make work. It is a tough sale. Does CMake have so many<br>
compelling features, protections, and conveniences to make it worth it?<br>
The project needs to answer that question for itself by trying it in<br>
parallel with what it is already doing.<br>
<br>
Finally, CMake is aggressive about deprecating features, its language is<br>
often just as arbitrary as the much hated autotools/automake stack, and<br>
it is now on its third attempt to regularize dependency detection for<br>
projects.  The deprecations mean significant configuration churn, and<br>
the dependency detection one is probably the most painful -- especially<br>
for projects that have been around a long time. These challenges mean<br>
trading one set of known annoyances with the current build stack for an<br>
unknown-to-the-project set. The problem is that a try-it-and-see cost to<br>
get started with such a substantial project as GDAL is very high.<br>
<span class="HOEnZb"><font color="#888888"><br>
Howard<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On 11/28/17 11:03 PM, Larry Shaffer wrote:<br>
> Hi All,<br>
><br>
> Apologies for top-posting, albeit the thread has stopped for ~month.<br>
><br>
> While I have not contributed that much to the GDAL project over the years,<br>
> I have build it a LOT (mostly on Win and macOS [0]). Switching to CMake<br>
> would be a good future-proof, cross-platform move, even if it is overly<br>
> verbose at times.<br>
><br>
> My concern, like others noted here, is that it will not necessarily be<br>
> greatly advantageous over the current build scripts. Unless... such an<br>
> endeavor leveraged some of CMake's more useful features, namely ease of<br>
> defining inter-library pre- or post-build-time dependencies, and external<br>
> projects.<br>
><br>
> *Make drivers plugins*<br>
> One of my biggest frustrations with building (and rebuilding) libgdal comes<br>
> from the default opportunistic way it finds and links against external libs<br>
> when configuring. Sure driver building can be controlled with options, but<br>
> why do I need to do this to build the *base* library? If libgdal was rarely<br>
> built and all drivers loaded as drivers, programs like QGIS wouldn't crash<br>
> because some obscure driver's lib changed (happens often with Homebrew).<br>
> This prompts a required rebuild of libgdal again.<br>
><br>
> I realize that this will take some extra work, and loading all drivers as<br>
> plugins may reduce some performance metric(s). The resulting CMake<br>
> configure options, though, could be specific to driver, not library, e.g.<br>
> -D GDAL_MRSID=ON would generate that plugin, building only the main libgdal<br>
> binary and any other dependent lib or driver plugins (none here) as needed.<br>
> Build time would be minimal, with the plugin immediately available for<br>
> distribution packaging.<br>
><br>
> Surely I'm not the only person who would love to see this, and CMake<br>
> porting would be the ideal time to craft this.<br>
><br>
> *External projects*<br>
> While Borsch has some awesome features, it currently requires out-of-tree<br>
> resources. If building GDAL with all dependencies local, like may be<br>
> required for a full static iOS build, is a goal, then the existing CMake<br>
> ExternalProject feature can be leveraged. A fine example of this is the<br>
> SuperBuild aspect of Orfeo ToolBox [1]. Such a setup could existing in-tree<br>
> for GDAL, though there is obvious overhead in maintaining<br>
> ExternalProject build scripts for many libs; so, maybe only for a standard<br>
> set makes sense.<br>
><br>
><br>
> Btw, CMake works very well on macOS and is my preferred build tool,<br>
> especially when used with Ninja generator.  :^)<br>
><br>
> [0] <a href="https://github.com/OSGeo/homebrew-osgeo4mac/tree/master/Formula" rel="noreferrer" target="_blank">https://github.com/OSGeo/<wbr>homebrew-osgeo4mac/tree/<wbr>master/Formula</a><br>
> [1] <a href="https://github.com/orfeotoolbox/OTB/tree/develop/SuperBuild" rel="noreferrer" target="_blank">https://github.com/<wbr>orfeotoolbox/OTB/tree/develop/<wbr>SuperBuild</a><br>
><br>
> Regards,<br>
><br>
> Larry Shaffer<br>
> Dakota Cartography<br>
> Black Hills, South Dakota<br>
> ------------------------------<wbr>----<br>
> Boundless Desktop and QGIS Support/Development<br>
> Boundless Spatial - <a href="http://boundlessgeo.com" rel="noreferrer" target="_blank">http://boundlessgeo.com</a><br>
> <a href="mailto:lshaffer@boundlessgeo.com">lshaffer@boundlessgeo.com</a><br>
><br>
> On Tue, Oct 31, 2017 at 5:54 AM, Mateusz Loskot <<a href="mailto:mateusz@loskot.net">mateusz@loskot.net</a>> wrote:<br>
><br>
>> On 30 October 2017 at 23:14, Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>><br>
>> wrote:<br>
>>> Trying to sum up my thoughts on this topic and answering to various<br>
>> 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<br>
>> the one that we would add" ?<br>
>><br>
>> Assuming multi-platform is the critical requirement, there are no real<br>
>> altenratives that beat CMake.<br>
>><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<br>
>> world, for the 20 next years<br>
>>> and beyond, and should run on all reasonable platforms, which build<br>
>> system would we use?<br>
>><br>
>> 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<br>
>> necessary.<br>
>><br>
>>> If the answer is clearly "cmake", then it is worth examining if there is<br>
>> not a path that<br>
>>> would lead us to that point.<br>
>> 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<br>
>> 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>
>><br>
>>> Similar question: is it an effort that will make GDAL development a bit<br>
>>> easier for new contributors?<br>
>> Perhaps, potentially, may be.<br>
>> Certainly, CMake makes development friendly for use with modern IDEs.<br>
>><br>
>>> A nice side effect could also be the opportunity to drop some cruft that<br>
>> has<br>
>>> accumulated over years in the current build systems (supporting ancient<br>
>>> library versions that no longer make sense)<br>
>> 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>
>><br>
>> Best regards,<br>
>> --<br>
>> Mateusz Loskot, <a href="http://mateusz.loskot.net" rel="noreferrer" target="_blank">http://mateusz.loskot.net</a><br>
>> ______________________________<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><br>
>><br>
><br>
><br>
> ______________________________<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><br>
<br>
<br>
</div></div><br>______________________________<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><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--<div><a href="http://schwehr.org" target="_blank">http://schwehr.org</a></div></div>
</div>