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".
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.
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.
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
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.
Even
Le 18/01/2022 à 14:06, Greg Troxel a écrit :
Even Rouault <even.roua...@spatialys.com> writes:
The new CMake build system
(https://gdal.org/development/rfc/rfc84_cmake.html) has made excellent
progress, and I believe that it should be in a production ready state
on time for GDAL 3.5.0 (~ May). It is already very close to it
according to a checklist I had created
(https://docs.google.com/spreadsheets/d/1SsUXiZxKim6jhLjlJFCRs1zwMvNpbJbBMB6yl0ms01c).
Do you mean that the master branch already has cmake support that you
believe 99% meets the requirements?
I think that establishing a date before the code meets requirement risks
a later decision to proceed anyway despite meeting the requirements. So
I'd like to flip this around to the steps needed, with the autoconf
removal decision gated on packager testing.
Specifically:
- Get master in a shape where the developers believe the requirements
are met. This includes build instructions, specifically about how
to get the right RPATH behavior. It's going to need testing
building to a prefix other than /usr and specifically a prefix not
in the default linker search path.
I'm unclear on the plan for the test suite. If running py-test in
the tests directory against an installed build still works, that's
fine -- I don't see a need to couple test improvements with the
cmake conversion.
- Produce an alpha tarball, following the same (documented) procedure
that would be used for a relaase in an autoconf-removed world. This
is what packagers package, and users hand build. Tarball creation
should be documented and scripted, so this should be a combination
of good testing and near-zero effort.
- Call for packager and user testing of the alpha tarball. Give them
1 full month, because converting a packaging build from autoconf to
cmake is not trivial, and because everything that depends on gdal
needs testing too. (In my case, the gdal build control files are
much bigger than typical packages.)
I expect to find problems, because I usually do on autoconf->cmake
transitions, and often around RPATH handling. But I will be happy
to report 100% success if that's how it is. And I'll try to do this
sooner rather than later.
- If there are any failures to meet requirements (including on systems
where gdal does not have CI; that's the point of the call for
testing), fix and release another alpha. 2 weeks is adequate
testing time, if the failures were minor enough to not prevent
getting to a working state.
- Once the report/fix cycle ends, then the autoconf removal can
proceed.
The above can be pipelined, if an alpha tarball can be produced that
90-95% meets requirements, enough that it's reasonable to do a draft
packaging conversion and end up with an installed gdal that one can
build a working qgis against.
Will this work for May? I don't know, and I think the big questions are
when a believed-requirements-meeting alpha tarball can be produced, and
how many residual issues there are. With a alpha in 2 weeks, the odds
are good. With an alpha on April 1, I don't see how it can work.
Greg
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
