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

[Javier Jimenez Shaw]

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

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.
.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ... .... ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos irracionales.



On Tue, 5 Oct 2021 at 14:51, Greg Troxel <gdt at lexort.com> wrote:

>
> Even Rouault <even.rouault at spatialys.com> writes:
>
> > Please find at https://github.com/OSGeo/gdal/pull/4590 a RFC that
> proposes:
> >
> > - to develop a CMake build system, officially integrated in the source
> tree.
> >
> > - and remove the current GNU makefiles and nmake build systems, when
> > the CMake build system has matured enough and reached feature parity.
>
> I added a comment that requirements should be stated and gave a first
> cut at them.  My big problem with cmake from packaging is that people
> write CMakefile code with OS-specific tests instead of feature tests and
> then packagers have to add lots of patches that add OS names to
> conditionals.  So the requireents should ban that practice in favor of
> feature tests.
>
> The other big comment is that "matured enough" is not just for what the
> project can test on CI, but the entire packaging world, so I included
> having a formal release with cmake where autoconf is marked deprecated
> for packagers to try to make work, so those issues can be fixed before a
> release without autoconf.  I get it that the project has CI for what
> they have, but I don't think that requirements should be driven by what
> CI exists.
>
> I'm willing to test on alpha/beta/rc; I can create a
> separate/work-in-progress package that is gdal alpha built with cmake,
> to flush out these things.
>
>
>
>
> _______________________________________________
> 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/20211005/603ee9f2/attachment-0001.html>