[gdal-dev] Removal of Python SWIG python generated files from git

[Daniel Evans]

Hi Even,

This sounds a sensible change, for the reasons outlined in your first
paragraph. When first making contributions, I think I was caught out
by this arrangement in just about all of the ways you mention!

To play devil's advocate, were there any (perceived) benefits to this
arrangement when originally introduced, other than not needing the
SWIG binary to compile Python bindings?

Regards,
Daniel

On Thu, 9 Mar 2023 at 18:14, Even Rouault <even.rouault at spatialys.com> wrote:
>
> Hi,
>
> take this email as a mini-RFC regarding the changes in
> https://github.com/OSGeo/gdal/pull/7390 which remove the SWIG python
> generated files from git master, and thus make the SWIG binary a
> requirement to build the Python bindings.
>
> Below, the text of the PR:
>
> This removes a long-time oddity where the SWIG generated .py and .cpp
> files were stored in git, which was inconvenient for contributors,
> requiring them to have a precise SWIG version and enabling a specific
> CMake variable to resync the generated files to the source files, and
> causing confusion to occasional contributors who sometimes accidentally
> submitted changes to generated files instead of their source files. This
> was also different from the Java and CSharp bindings, which didn't have
> the generated files in git and required SWIG to be available to generate
> them.
>
> Bonus of this move: in the process, due to some of our most up to date
> CI targets using SWIG 4.1, it enabled to fix 2 errors in SWIG syntax
> that were rejected by SWIG 4.1 (and hidden up to now due to using 4.0.2
> as our baseline)
>
> This change shouldn't be a major hurdle for distributors, as most known
> binary distributions did regenerate the files anyway.
>
> Note to people updating an existing git checkout: now the
> BUILD_JAVA/CSHARP/PYTHON_BINDINGS CMake variables are strictly honored.
> They are now initialized to ON only if all build requirements are
> available (SWIG and Python for the python bindings), and if set to ON
> but a requirement is missing, CMake fails. This might cause issues for
> people for example not having the requirements for the Java or CSharp
> bindings, but with an existing CMakeCache.txt with them set. Fix: run
> "cmake -UBUILD_JAVA_BINDINGS -UBUILD_CHSARP_BINDINGS
> -UBUILD_PYTHON_BINDINGS"
>
> Even
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev