[gdal-dev] Shortening schedule for CMake adoption ?

[Greg Troxel]

Even Rouault <even.rouault at 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
-------------- 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/df717742/attachment.sig>