Even Rouault <[email protected]> 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.
signature.asc
Description: PGP signature
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
