[gdal-dev] RFC 84: Migrating build systems to CMake

Robert Coup robert.coup at koordinates.com
Wed Oct 6 03:19:52 PDT 2021


(on-list)

Hi,

On Tue, 5 Oct 2021 at 14:16, Javier Jimenez Shaw <j1 at jimenezshaw.com> wrote:

> How would CMake behave with all those options that are defined depending
> on what is present on the compiler machine?
>

This is orthogonal to CMake vs Make, but the RFC does discuss cleaning up
consistency of build options cross-platform and the opt-in/out of building
drivers.

In general, for most people building I think we want the build to
automatically pick up the libraries/formats/options that are available so
it works for them with minimal effort. But we should set it up, as Kurt
mentioned, for builders to easily be able to "opt-out" of (nearly) every
driver and then selectively re-enable them (& obviously their dependency
requirements) as needed.

Different distributions have different approaches here — some build with
basically every possible option & dependency enabled ("the kitchen sink"),
others build with limited dependencies and as a user if you want to turn on
anything else then you'll need to rebuild it yourself.

IMHO, the libraries included should be independent on what is already
> installed on the compiler machine. The last time something/somebody
> included "zstd" in our compiler machine, and not in the executing machine,
> and we couldn't run anything. We did not need zstd, but it was there,
> breaking the execution. I know that the solution there is disable it
> "--without-zstd". What I do not like is the lack of definition, because
> what is present on the compiler machine may change.
>

If you are packaging for distribution (within an org or publicly), being
careful about which dependencies/versions/etc are available is a regular
issue which projects like GDAL shouldn't try to overly control — everything
needs to be built in an isolated environment, be it a container,
fakeroot/chroot, or something else. Downstream packagers for Linux/BSD/etc
all are very careful to do this, it's not a new problem.

Rob :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20211006/616c2029/attachment-0001.html>


More information about the gdal-dev mailing list