(on-list)
Hi,
On Tue, 5 Oct 2021 at 14:16, Javier Jimenez Shaw <j...@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 :-)
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
