[gdal-dev] Shortening schedule for CMake adoption ?

[Greg Troxel]

Even Rouault <even.rouault at spatialys.com> writes:

> Greg,
>
> I will not respond point by point, but the message here is: "CMake
> support is available and believed to be in good shape into master
> based on our manual tests and initial CI configuration exercising it,
> it will replace autotools+nmake soon, be ready for it and help
> polishing it". 

OK, that's great to hear.  As someone who is here mainly as a packager,
I don't subscribe to github, and I haven't seen anything on gdal-dev@
saying that cmake support is ready for widespread testing (but now I
have!).

> There will perhaps be areas where it will not do
> everything that existing build systems made, but existing build
> systems have also their flows that are not easily fixable. So be
> it. Having one single build system at the end of the process, and used
> in an idiomatic way (our autoconf system without automake is far from
> being idiomatic), is the main objective of this whole effort from my
> side.

Sure, I get it that there will be a few rough edges.

> CMake might not be completely ready for 3.5.0 for all imaginable
> platforms & configurations (we don't promise to support all platforms
> anyway. I don't believe we have a formal list of supported platforms
> by the way. I'd say what is tested on our CI is the practical
> definition of what is supported), and we won't defer indefinitely
> 3.5.0 if it doesn't work on some confs. That's why autoconf&nmake will
> only be removed in 3.6.0, and we have 3.5.x point releases to help
> address issues.

Sorry, I misunderstood that the autoconf removal would not be for this
release.  As long as I can use the existing autoconf support for 3.5.0
if I have to, things are much less tense.

And yes, I realize that "supported platforms" is a difficult concept.
But here we're talking about a big change that risks regresssions to
platforms people have already made work, so I see it more as "we should
really avoid causing regressions on platforms known to work".

As a random datpoint, I have updated gdal in pkgsrc to 3.4.1 (not yet
committed it), tested on NetBSD 9 amd64, and the tests have only a
handful of failures that perhaps could be test issues.  And qgis with
this build works ok as far as I can tell.

> The release process  is described in HOWTO-RELEASE and it points to
> the mkgdaldist.sh script
>
> You can generate a gdal-master.tar.gz with:
>
> ./mkgdaldist.sh master -branch master
>
> No idea if the script works properly on non-Linux systems. You'll need
> some prerequisites for the script to run: Sphinx (pip install -r 
> doc/requirements.txt) to generate man pages, swig

I'll try that, but I think you'll get a lot more testing from packagers
if you publish an alpha tarball.

> Or just clone the git repo and rm -rf autotest .git .github, and that
> will be very close to the final tarball, at least for the purpose of
> doing a CMake build
>
> and try packaging this.

I'll try that if the above doesn't work.

And actually I can try a cmake build from the repo, which is probably a
good first step.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20220118/a76c344d/attachment-0001.sig>