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

[Howard Butler]

I'm in Frank's camp.  I want generated stuff in the repository as a 
"last known good" sort of solution.  GEOS has taken this strategy of 
updating snapshots instead of keeping generated stuff in SVN and it 
has for all practical purposes killed my involvement with it as a 
Windows maintainer/developer.

Would it be possible to svn-hook the generation and commit of 
interface files whenever ./swig is commited on?  This might not take 
away the conflict problem, however.  This is probably too fragile.

Howard



At 12:18 PM 1/23/2007, Daniel Morissette wrote:
>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/
>_______________________________________________
>Gdal-dev mailing list
>Gdal-dev at lists.maptools.org
>http://lists.maptools.org/mailman/listinfo/gdal-dev