[GRASS-dev] SWIG-Python lacking from install sequence in main Makefile

neteler · July 17, 2009, 9:15pm

Hi,

still SWIG-Python is lacking from install sequence in main Makefile.
Is there a reason for that? Say, how to use the examples like
rasteraccess.py when I have "just" the installed GRASS version?

Markus

Glynn_Clements1 · July 18, 2009, 4:48am

Markus Neteler wrote:

still SWIG-Python is lacking from install sequence in main Makefile.
Is there a reason for that? Say, how to use the examples like
rasteraccess.py when I have "just" the installed GRASS version?

Installation shouldn't need any special treatment in the top-level
Makefile.

6.x still doesn't build the swig directory, but 7.0 does.

--
Glynn Clements <glynn@gclements.plus.com>

Hamish · July 18, 2009, 6:14am

Glynn wrote:

6.x still doesn't build the swig directory, but 7.0 does.

to remind from an earlier thread:

building relbr6.4 swig/python/ from Debian/Etch (swig version 1.3.29-2.1)
fails with:

[...]
utils_wrap.c: In function 'pyseq_to_ptr':
utils_wrap.c:2495: error: 'Py_ssize_t' undeclared (first use in this function)
utils_wrap.c:2495: error: (Each undeclared identifier is reported only once
utils_wrap.c:2495: error: for each function it appears in.)
utils_wrap.c:2495: error: expected ';' before 'len'
utils_wrap.c:2522: error: 'len' undeclared (first use in this function)
utils_wrap.c: In function 'pyobj_to_ptr':
utils_wrap.c:2570: error: 'Py_ssize_t' undeclared (first use in this function)
[...]

up until a couple of 6.4 RCs ago it built ok.

Hamish

neteler · July 19, 2009, 4:21pm

On Sat, Jul 18, 2009 at 6:48 AM, Glynn Clements<glynn@gclements.plus.com> wrote:

Markus Neteler wrote:

still SWIG-Python is lacking from install sequence in main Makefile.
Is there a reason for that? Say, how to use the examples like
rasteraccess.py when I have "just" the installed GRASS version?

Installation shouldn't need any special treatment in the top-level
Makefile.

Right.

6.x still doesn't build the swig directory, but 7.0 does.

Now GRASS 6.4 + 6.5 do, I have updated
Makefile
swig/Makefile
accordingly.

Markus

neteler · July 19, 2009, 4:25pm

On Sat, Jul 18, 2009 at 8:14 AM, Hamish<hamish_b@yahoo.com> wrote:

Glynn wrote:

6.x still doesn't build the swig directory, but 7.0 does.

to remind from an earlier thread:

building relbr6.4 swig/python/ from Debian/Etch (swig version 1.3.29-2.1)
fails with:

[...]
utils_wrap.c: In function 'pyseq_to_ptr':
utils_wrap.c:2495: error: 'Py_ssize_t' undeclared (first use in this function)
utils_wrap.c:2495: error: (Each undeclared identifier is reported only once
utils_wrap.c:2495: error: for each function it appears in.)
utils_wrap.c:2495: error: expected ';' before 'len'
utils_wrap.c:2522: error: 'len' undeclared (first use in this function)
utils_wrap.c: In function 'pyobj_to_ptr':
utils_wrap.c:2570: error: 'Py_ssize_t' undeclared (first use in this function)
[...]

See
http://n2.nabble.com/grass7-build-failing-for-swig-python-td3074306.html

and
http://www.mail-archive.com/bug-gnubg@gnu.org/msg03894.html
http://www.mail-archive.com/bug-gnubg@gnu.org/msg03895.html

So, specific to the version which you use.

Markus

Hamish · July 19, 2009, 9:33pm

Hamish:

> building relbr6.4 swig/python/ from Debian/Etch (swig
> version 1.3.29-2.1) fails with:
>
> [...]
> utils_wrap.c: In function 'pyseq_to_ptr':
> utils_wrap.c:2495: error: 'Py_ssize_t' undeclared (first use in this function)
> utils_wrap.c:2495: error: (Each undeclared identifier is reported only once
> utils_wrap.c:2495: error: for each function it appears in.)
> utils_wrap.c:2495: error: expected ';' before 'len'
> utils_wrap.c:2522: error: 'len' undeclared (first use in this function)
> utils_wrap.c: In function 'pyobj_to_ptr':
> utils_wrap.c:2570: error: 'Py_ssize_t' undeclared
(first use in this function)
> [...]

Markus:

See
http://n2.nabble.com/grass7-build-failing-for-swig-python-td3074306.html

and
http://www.mail-archive.com/bug-gnubg@gnu.org/msg03894.html
http://www.mail-archive.com/bug-gnubg@gnu.org/msg03895.html

So, specific to the version which you use.

As it is a >= version issue and not a bug in a specific release,
some sort of #ifdef MAJOR_VERSION && MINOR_VERSION test around
a #include <Python.h> seems in order.

Hamish

Hamish · July 20, 2009, 12:43am

Hamish:
> > building relbr6.4 swig/python/ from Debian/Etch (swig
> > version 1.3.29-2.1) fails with:
> > [...]
> > utils_wrap.c: In function 'pyseq_to_ptr':
> > utils_wrap.c:2495: error: 'Py_ssize_t' undeclared (first use in this function)
> > [...]

Markus:
> See
> http://n2.nabble.com/grass7-build-failing-for-swig-python-td3074306.html
>
> and
> http://www.mail-archive.com/bug-gnubg@gnu.org/msg03894.html
> http://www.mail-archive.com/bug-gnubg@gnu.org/msg03895.html
>
> So, specific to the version which you use.

Hamish:

As it is a >= version issue and not a bug in a specific release,
some sort of #ifdef MAJOR_VERSION && MINOR_VERSION test around
a #include <Python.h> seems in order.

I am trying to find where to handle something like that,
- utils*.c is auto-generated by swig.
- Python.h is found by ./configure and stored in Platform.make:PYTHONINC
and PYTHONCFLAGS
- Can something be added to the utils_wrap.c: Makefile rule ???

also from swig/python/README todo item: at build-time we should byte
compile the .pyc version of our python libs so that users do not have
to wait a long time the first time they run GRASS. If installed without
write permissions by normal users (typical case for packaged Linux
anyway) .pyc files will not be cached and startup will always take a
long time.

e.g. on WinGRASS the wxGUI takes /very/ long to start up, with no feedback
except for hard drive access LED that anything is happening for like 20
seconds (ok, slow classmate PC netbook, but..) I am not totally sure
this is the main cause of that delay, but I'd wager that it doesn't help.

Hamish

Hamish · July 20, 2009, 1:01am

> Hamish:
building relbr6.4 swig/python/ from Debian/Etch (swig
version 1.3.29-2.1) fails with:
[...]
utils_wrap.c: In function 'pyseq_to_ptr':
utils_wrap.c:2495: error: 'Py_ssize_t' undeclared (first use in this function)
[...]

....

> a #include <Python.h> seems in order.

I am trying to find where to handle something like that,
- utils*.c is auto-generated by swig.
- Python.h is found by ./configure and stored in Platform.make:PYTHONINC
and PYTHONCFLAGS
- Can something be added to the utils_wrap.c: Makefile rule ???

hmmm. utils_wrap.c has:

/* Python.h has to appear first */
#include <Python.h>

and make correctly includes -I/usr/include/python2.4,
gcc -I/usr/local/src/grass/svn/releasebranch_6_4/dist.i686-pc-linux-gnu/include -ggdb -march=pentium4 -Wall -Werror-implicit-function-declaration -fPIC -DPACKAGE=\""grasslibs"\" -fPIC -I/usr/include/python2.4 -I/usr/include/python2.4 -DPACKAGE=\""grasslibs"\" -I/usr/local/src/grass/svn/releasebranch_6_4/dist.i686-pc-linux-gnu/include -o OBJ.i686-pc-linux-gnu/utils_wrap.o -c utils_wrap.c
utils_wrap.c: In function 'pyseq_to_ptr':
utils_wrap.c:2496: error: 'Py_ssize_t' undeclared (first use in this function)
utils_wrap.c:2496: error: (Each undeclared identifier is reported only once
utils_wrap.c:2496: error: for each function it appears in.)

but /usr/include/python2.4/ headers only mentions 'Py_ssize_t' in a
comment of pymem.h.
In python 2.5 include files it is defined in pyport.h.

so (IIUC) swig 1.3.29 requires python >= 2.5 ?

Hamish

Hamish · July 20, 2009, 1:14am

Hamish:

so (IIUC) swig 1.3.29 requires python >= 2.5 ?

I can get a little further if I iteratively add this patch to *_wrap.c:

--- grass_wrap.c.ORIG 2009-07-20 13:06:52.000000000 +1200
+++ grass_wrap.c 2009-07-20 13:07:15.000000000 +1200
@@ -111,6 +111,11 @@
/* Python.h has to appear first */
#include <Python.h>

+/* needed for Python 2.4 */
+#ifndef Py_ssize_t
+typedef size_t Py_ssize_t;
+#endif
+
/* -----------------------------------------------------------------------------
* swigrun.swg
*

until I get to proj_wrap.c which then fails with:

In file included from proj_wrap.c:2660:
/usr/local/src/grass/svn/releasebranch_6_4/dist.i686-pc-linux-gnu/
include/grass/gprojects.h:23:29: error: ogr_srs_api.h: No such file or directory

(ogr_srs_api.h is present in /usr/include/gdal/)

Hamish

Glynn_Clements1 · July 20, 2009, 3:53am

Hamish wrote:

so (IIUC) swig 1.3.29 requires python >= 2.5 ?

FWIW, the wrappers generated by SWIG 1.3.36 have:

  /* Py_ssize_t for old Pythons */
  /* This code is as recommended by: */
  /* http://www.python.org/dev/peps/pep-0353/#conversion-guidelines */
  #if PY_VERSION_HEX < 0x02050000 && !defined(PY_SSIZE_T_MIN)
  typedef int Py_ssize_t;
  # define PY_SSIZE_T_MAX INT_MAX
  # define PY_SSIZE_T_MIN INT_MIN
  #endif

IOW, you should just need a newer version of SWIG.

--
Glynn Clements <glynn@gclements.plus.com>

Hamish · July 20, 2009, 5:27am

Hamish:

> so (IIUC) swig 1.3.29 requires python >= 2.5 ?

Glynn:

FWIW, the wrappers generated by SWIG 1.3.36 have:

....

IOW, you should just need a newer version of SWIG.

aka ask users to upgrade their OS in order to install a user app. :-/

If this can not be worked around, anyone know what the minimum required
swig version is?
Then we can at least document --with-python in REQUIREMENTS.html
Would it be like swig >= 1.3.x OR python >= 2.5 ?

it passes all the --with-python checks, could ./configure be improved
to bail if actual requirements are not met?
....
checking whether to use Python... yes
checking for python-config... /usr/bin/python2.4-config
checking for Python.h... yes
checking for swig... /usr/bin/swig
....

thanks,
Hamish