[Gdal-dev] Motion: Adding the SWIG generated files to the SVN repository

[Daniel Morissette]

I'll vote -0 on this for similar reasons as what Mateusz explained.

I understand Frank's concerns that GDAL should be as easy as possible to 
build, but the SWIG C# stuff is a wrapper on top of GDAL, it's not part 
of the core, so I would argue that those files will be useful only for 
someone who needs to work on the development version of GDAL from SVN 
and needs to work with C# and doesn't have SWIG available, that's a 
fairly specialized case and that doesn't justify all the trouble that 
Mateusz explained.

A less intrusive solution could be to have an automated script build a 
daily snapshot of the SWIG wrappers and make them available on the 
download site. Then the makefiles could spit out an error if the 
wrappers are missing and SWIG is not available, telling the developer to 
either install SWIG or download the wrappers in order to build the C# 
interface.

My 0.02$

Daniel

Tamas Szekeres wrote:
> Dear All,
> 
> It seems to me that many of the developers would favour adding the
> SWIG generated files to the SVN repository. Currently for some of the
> bindings the generated files are already inside, but  the others like
> C# doesn't have these files version controlled.
> 
> The primary benefit of this solution that it would eliminate the need
> to have the SWIG installed for those who want to compile the binaries
> from the source. In addition the interface maintainer could choose the
> most appropriate SWIG version to generate the files.
> 
> However there are some disdvantages when applying this concept, as:
> 
> 1. For some of the bindings SWIG generates high number of the files.
> For the C# interface currently the following files should be added:
> 
> Directory of \gdal\swig\csharp\const
> 
> gdalconst.cs
> gdalconstPINVOKE.cs
> gdalconst_wrap.c
> 
> Directory of \gdal\swig\csharp\gdal
> 
> Band.cs
> ColorEntry.cs
> ColorTable.cs
> Dataset.cs
> Driver.cs
> GCP.cs
> gdal.cs
> gdalPINVOKE.cs
> gdal_wrap.cpp
> MajorObject.cs
> SWIGTYPE_p_CPLErrorHandler.cs
> SWIGTYPE_p_FALSE_IS_ERR.cs
> SWIGTYPE_p_GByte.cs
> SWIGTYPE_p_int.cs
> SWIGTYPE_p_p_char.cs
> SWIGTYPE_p_p_GDAL_GCP.cs
> XMLNode.cs
> XMLNodeType.cs
> 
> Directory of \gdal\swig\csharp\ogr
> 
> CoordinateTransformation.cs
> DataSource.cs
> Driver.cs
> Envelope.cs
> Feature.cs
> FeatureDefn.cs
> FieldDefn.cs
> Geometry.cs
> Layer.cs
> ogr.cs
> ogrPINVOKE.cs
> ogr_wrap.cpp
> osr.cs
> osrPINVOKE.cs
> osr_wrap.cpp
> SpatialReference.cs
> SWIGTYPE_p_p_char.cs
> 
> Directory of \gdal\swig\csharp\osr
> 
> CoordinateTransformation.cs
> osr.cs
> osrPINVOKE.cs
> osr_wrap.cpp
> SpatialReference.cs
> SWIGTYPE_p_p_char.cs
> 
> 
> Upon modifying the C# interface files (.i) sometimes all of the
> generated files may vary, some of the files might be deleted renamed
> or added.  Therefore the maintainability of these files might bring in
> some additional complexity.
> 
> 
> 2. If different people with different swigs generate these files they
> will potentially clobber each other in the repository and even
> generate conflicts. Here is an example taken out of a post in the
> geos-dev list:
> 
> A checks out
> B checks out
> A generates and updates and commits
> B generates and updates, conflict!
> 
> 
> 
> Before applying such changes I would like to know how the folks can
> live with this idea. When I get some positive confirmation I'm ready
> to make it for the SWIG C# binding.
> 
> I would start a vote on this approval with a +0 on my side.
> 
> 
> Best Regards,
> _______________________________________________
> Gdal-dev mailing list
> Gdal-dev at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/gdal-dev


-- 
Daniel Morissette
http://www.mapgears.com/