Python bindings don't build on Mandriva 2009.1

[Even Rouault]

We get the following error log :

python setup.py install --prefix=/usr/local
setup.py:78: DeprecationWarning: The popen2 module is deprecated.  Use the subprocess module.
  import popen2
running install
running build
running build_py
running build_ext
building 'osgeo._gdal' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -Wformat
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
 --param=ssp-buffer-size=4 -fomit-frame-pointer -march=i586 -mtune=generic
 -fasynchronous-unwind-tables -g -fPIC -I../../port -I../../gcore -I../../alg 
-I../../ogr/ -I/usr/include/python2.6 -I. -I/home/even/1.6/gdal/include
-c extensions/gdal_wrap.cpp -o build/temp.linux-i686-2.6/extensions/gdal_wrap.o
extensions/gdal_wrap.cpp: In function ‘void SWIG_Python_AddErrorMsg(const char*)’:
extensions/gdal_wrap.cpp:870: erreur: le format n'est pas une chaîne littérale et pas d'argument de format
extensions/gdal_wrap.cpp: In function ‘void Debug(const char*, const char*)’:
extensions/gdal_wrap.cpp:2695: erreur: le format n'est pas une chaîne littérale et pas d'argument de format
extensions/gdal_wrap.cpp: In function ‘void Error(CPLErr, int, const char*)’:
extensions/gdal_wrap.cpp:2698: erreur: le format n'est pas une chaîne littérale et pas d'argument de format
extensions/gdal_wrap.cpp: In function ‘PyObject* _wrap_MajorObject_SetMetadata__SWIG_0(PyObject*, PyObject*)’:
extensions/gdal_wrap.cpp:5007: attention : deprecated conversion from string constant to ‘char*’
error: command 'gcc' failed with exit status 1
make: *** [install] Erreur 1

The GCC options used by Python on this distro are very strict and they forbid the use of "printf(str);"-like constructs. We should rather use "printf("%s", str)".

The fix to follow will correct the related errors in cpl.i. But there's a similar problem in a swig file itself (pyerrors.swg). This was fixed in (at least) SWIG 1.3.36. But as I'm reluctant to upgrade swig version for 1.6.1, for the moment, I'll use a GNUMakefile hack based on sed to correct the offending generated code.

[Even Rouault]

Fixed in trunk (r16923) and in branches/1.6 (r16924)

[Markus Neteler]

I appreciate the coincidence :)

Something is yet strange:

rm -rf swig
svn up swig

# compile stuff
svn status
?       swig/csharp/gdal/RATFieldUsage.cs     
?       swig/csharp/gdal/RATFieldType.cs      
?       swig/csharp/gdal/RasterAttributeTable.cs
?       swig/csharp/gdal/Transformer.cs
?       swig/java/gdal_wrap.cpp
?       swig/java/org
?       swig/java/gdalconst_wrap.c
?       swig/java/ogr_wrap.cpp
?       swig/java/osr_wrap.cpp
M       swig/python/extensions/gdal_wrap.cpp
M       swig/python/extensions/ogr_wrap.cpp
M       swig/python/extensions/gdalconst_wrap.c
M       swig/python/extensions/osr_wrap.cpp
M       swig/python/osgeo/gdalconst.py
M       swig/python/osgeo/osr.py
M       swig/python/osgeo/gdal.py
M       swig/python/osgeo/ogr.py
M       swig/ruby/gdal_wrap.cpp
M       swig/ruby/ogr_wrap.cpp
M       swig/ruby/gdalconst_wrap.c
M       swig/ruby/osr_wrap.cpp
M       swig/perl/gdal_wrap.cpp
M       swig/perl/gdalconst_wrap.c
M       swig/perl/ogr_wrap.cpp
M       swig/perl/lib/Geo/GDAL.pm
M       swig/perl/lib/Geo/OGR.pm
M       swig/perl/lib/Geo/GDAL/Const.pm
M       swig/perl/lib/Geo/OSR.pm
M       swig/perl/osr_wrap.cpp

Differences?? This indicates that the files should either not be in SVN or that they are oldish in SVN. At least it is the first case for me that a code compilation triggers differences to SVN. This is dangerous in a sense than an accidental commit could ruin code in SVN (maybe svn ignore is needed?)

Markus

[Even Rouault]

In fact, depending on the bindings, the generated cpp files are put in SVN too. This is for example the case for Python. We regularly upload the generated files for Python bindings when we modify the swig .i files. So why do you see differences ? Because you have swig installed, and your version is != 1.3.31 (the version used to generate SVN cpp files). I think the idea of having the cpp files in SVN is that we don't need to make having swig installed a requirement for building GDAL.

I see that Ruby and PHP also have their cpp files in SVN, but as they are unmaintened, I don't think we should really refresh the cpp files.

The other remaining case is Perl. I see they haven't been regenerated for a long time (more than 1 year) and apparently not even for 1.6.0 release...

And Java and C# haven't their cpp files in SVN.

Gdal-devs ?

[Ari Jolma]

I wouldn't like to have the generated files in svn, but that was a policy decision a long time ago to keep them there. I'm not updating the generated files - I have understood that making a release includes rebuilding the wrappers. I often play around with the .i and other files so my wrapper files are often regenerated.

Ari

[tamas]

I'm forcefully opposed to placing SWIG generated output files in SVN because it's difficult to update dozens of files along with even a single change in an interface file for example. I think it's not a big requirement for the user to install SWIG when he makes his hands dirty by compiling the bindings manually.

[hobu]

I'm generally opposed to keeping generated swig output in svn as well. If our policy was that the distribution-generating machine did the swig generation, that would be sufficient for me.

It would be better to say, "we support SWIG versions 1.3.x - 1.3.x+y" and then pick a minimum version for the distribution machine.

What was the case for keeping this stuff in subversion in the first place?

[Markus Neteler]

Replying to tamas:

I'm forcefully opposed to placing SWIG generated output files in SVN because it's difficult to update dozens of files along with even a single change in an interface file for example. I think it's not a big requirement for the user to install SWIG when he makes his hands dirty by compiling the bindings manually.

I agree - the GRASS SWIG bindings in SVN are reduced to the minimum to build them with SWIG. Like this no mess happens (and running "make" isn't that hard). Avoids lots of SVN conflicts.

[Even Rouault]

The discussion about swig generated files in SVN or not has moved into gdal-dev. Closing this ticket