Re: [gdal-dev] Removal of Python SWIG python generated files from git
I am also okay with removing the files. I think removing the generated files will help the project's health. At Google, we have used the swig generated files from git for the python interfaces. It was helpful as we don't have a lot of control about which swig version is available. However, it's now not that hard to run swig separately from our bazel based build with a specific version of swig that works and copying the files over. Thanks! -Kurt On Thu, Mar 9, 2023 at 12:37 PM Frank Warmerdam wrote: > Folks, > > At one time we were very sensitive to the exact version of SWIG so > providing pre-generated bindings removed a large class of versioning > problems. > > I am ok with removing them. > > Best regards, > Frank > > > On Thu, Mar 9, 2023 at 3:14 PM Even Rouault > wrote: > >> >> > 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? >> >> That predates the start of my involvement with GDAL, so my guess would >> be that this was just what you mention: for the sake of simplicity of >> people building GDAL, at a time where its only build requirement was the >> basic tools autoconf, make and g++. Nowadays, getting SWIG isn't harder >> than getting PROJ or any of the "optional" dependencies you generally >> want to make a reasonably feature complete GDAL build. >> >> Even >> >> -- >> 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 >> > > > -- > > ---+-- > I set the clouds in motion - turn up | Frank Warmerdam, > warmer...@pobox.com > light and sound - activate the windows | +1 650-701-7823 > and watch the world go round - Rush| Geospatial Software Developer > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Removal of Python SWIG python generated files from git
Folks, At one time we were very sensitive to the exact version of SWIG so providing pre-generated bindings removed a large class of versioning problems. I am ok with removing them. Best regards, Frank On Thu, Mar 9, 2023 at 3:14 PM Even Rouault wrote: > > > 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? > > That predates the start of my involvement with GDAL, so my guess would > be that this was just what you mention: for the sake of simplicity of > people building GDAL, at a time where its only build requirement was the > basic tools autoconf, make and g++. Nowadays, getting SWIG isn't harder > than getting PROJ or any of the "optional" dependencies you generally > want to make a reasonably feature complete GDAL build. > > Even > > -- > 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 > -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | +1 650-701-7823 and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Removal of Python SWIG python generated files from git
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? That predates the start of my involvement with GDAL, so my guess would be that this was just what you mention: for the sake of simplicity of people building GDAL, at a time where its only build requirement was the basic tools autoconf, make and g++. Nowadays, getting SWIG isn't harder than getting PROJ or any of the "optional" dependencies you generally want to make a reasonably feature complete GDAL build. Even -- 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
Re: [gdal-dev] Removal of Python SWIG python generated files from git
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 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@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
