[GRASS-dev] ctypes not working in 6.x, differences between 6.x and 7.0

GRASS GRASS developer
1

The stuff created in lib/python/ctypes differs between 6.x and 7.0,
the 6.x versions being rather messy.

The Make system in 6.x should be updated to clean up the mess,
particularly that z lib to avoid the following error on 64bit Linux:
/lib/libz.so.1: wrong ELF class: ELFCLASS32

IMHO, the solution should not be a hack that removes _libs["z"] afterwards.

sniplet from e.g. /lib/python/ctypes/vector.py in 7.0

[snip-->]

add_library_search_dirs()

# Begin libraries

_libs["grass_vector.7.0.svn"] = load_library("grass_vector.7.0.svn")
_libs["grass_dig2.7.0.svn"] = load_library("grass_dig2.7.0.svn")
_libs["grass_dgl.7.0.svn"] = load_library("grass_dgl.7.0.svn")
_libs["grass_rtree.7.0.svn"] = load_library("grass_rtree.7.0.svn")
_libs["grass_linkm.7.0.svn"] = load_library("grass_linkm.7.0.svn")
_libs["grass_dbmiclient.7.0.svn"] = load_library("grass_dbmiclient.7.0.svn")
_libs["grass_dbmibase.7.0.svn"] = load_library("grass_dbmibase.7.0.svn")
_libs["grass_btree2.7.0.svn"] = load_library("grass_btree2.7.0.svn")
_libs["grass_gproj.7.0.svn"] = load_library("grass_gproj.7.0.svn")

# 9 libraries
# End libraries

[<--snip]

and in 6.x:

[snip-->]

add_library_search_dirs()

# Begin libraries
_libs["grass_vect.6.5.svn"] = load_library("grass_vect.6.5.svn")
_libs["grass_dbmibase.6.5.svn"] = load_library("grass_dbmibase.6.5.svn")
_libs["grass_gis.6.5.svn"] = load_library("grass_gis.6.5.svn")
_libs["grass_datetime.6.5.svn"] = load_library("grass_datetime.6.5.svn")
_libs["z"] = load_library("z")
_libs["grass_dbmiclient.6.5.svn"] = load_library("grass_dbmiclient.6.5.svn")
_libs["grass_dbmibase.6.5.svn"] = load_library("grass_dbmibase.6.5.svn")
_libs["grass_gis.6.5.svn"] = load_library("grass_gis.6.5.svn")
_libs["grass_datetime.6.5.svn"] = load_library("grass_datetime.6.5.svn")
_libs["z"] = load_library("z")
_libs["grass_gis.6.5.svn"] = load_library("grass_gis.6.5.svn")
_libs["grass_datetime.6.5.svn"] = load_library("grass_datetime.6.5.svn")
_libs["z"] = load_library("z")
_libs["grass_dgl.6.5.svn"] = load_library("grass_dgl.6.5.svn")
_libs["grass_dig2.6.5.svn"] = load_library("grass_dig2.6.5.svn")
_libs["grass_gis.6.5.svn"] = load_library("grass_gis.6.5.svn")
_libs["grass_datetime.6.5.svn"] = load_library("grass_datetime.6.5.svn")
_libs["z"] = load_library("z")
_libs["grass_rtree.6.5.svn"] = load_library("grass_rtree.6.5.svn")
_libs["grass_gis.6.5.svn"] = load_library("grass_gis.6.5.svn")
_libs["grass_datetime.6.5.svn"] = load_library("grass_datetime.6.5.svn")
_libs["z"] = load_library("z")
_libs["grass_linkm.6.5.svn"] = load_library("grass_linkm.6.5.svn")
_libs["grass_rtree.6.5.svn"] = load_library("grass_rtree.6.5.svn")
_libs["grass_dig2.6.5.svn"] = load_library("grass_dig2.6.5.svn")
_libs["grass_gis.6.5.svn"] = load_library("grass_gis.6.5.svn")
_libs["grass_datetime.6.5.svn"] = load_library("grass_datetime.6.5.svn")
_libs["z"] = load_library("z")
_libs["grass_rtree.6.5.svn"] = load_library("grass_rtree.6.5.svn")
_libs["grass_dgl.6.5.svn"] = load_library("grass_dgl.6.5.svn")
_libs["grass_rtree.6.5.svn"] = load_library("grass_rtree.6.5.svn")
_libs["grass_linkm.6.5.svn"] = load_library("grass_linkm.6.5.svn")
_libs["grass_dbmiclient.6.5.svn"] = load_library("grass_dbmiclient.6.5.svn")
_libs["grass_dbmibase.6.5.svn"] = load_library("grass_dbmibase.6.5.svn")
_libs["grass_gis.6.5.svn"] = load_library("grass_gis.6.5.svn")
_libs["grass_datetime.6.5.svn"] = load_library("grass_datetime.6.5.svn")
_libs["z"] = load_library("z")
_libs["grass_gis.6.5.svn"] = load_library("grass_gis.6.5.svn")
_libs["grass_datetime.6.5.svn"] = load_library("grass_datetime.6.5.svn")
_libs["z"] = load_library("z")
_libs["grass_dbmibase.6.5.svn"] = load_library("grass_dbmibase.6.5.svn")
_libs["grass_gis.6.5.svn"] = load_library("grass_gis.6.5.svn")
_libs["grass_datetime.6.5.svn"] = load_library("grass_datetime.6.5.svn")
_libs["z"] = load_library("z")

# 44 libraries
# End libraries

[<--snip]

Thanks,

Markus M

2

Hi,

2011/4/18 Markus Metz <markus.metz.giswork@googlemail.com>:

The stuff created in lib/python/ctypes differs between 6.x and 7.0,
the 6.x versions being rather messy.

The Make system in 6.x should be updated to clean up the mess,
particularly that z lib to avoid the following error on 64bit Linux:
/lib/libz.so.1: wrong ELF class: ELFCLASS32

right, I would be happy to backport GRASS 7 Makefile system to GRASS
6. It would solve most of problems, make backporting easier. We just
need to extend Makefile system in GRASS 7 to support Bash scripts.
What do you think about that?

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

3

On Mon, Apr 18, 2011 at 11:57 AM, Martin Landa <landa.martin@gmail.com> wrote:

Hi,

2011/4/18 Markus Metz <markus.metz.giswork@googlemail.com>:

The stuff created in lib/python/ctypes differs between 6.x and 7.0,
the 6.x versions being rather messy.

The Make system in 6.x should be updated to clean up the mess,
particularly that z lib to avoid the following error on 64bit Linux:
/lib/libz.so.1: wrong ELF class: ELFCLASS32

right, I would be happy to backport GRASS 7 Makefile system to GRASS
6. It would solve most of problems, make backporting easier. We just
need to extend Makefile system in GRASS 7 to support Bash scripts.
What do you think about that?

"just" ? I remember Glynn had objections against both python and shell
script support in the Makefile system.

Regarding ctypes, fixing lib/python/ctypes/Makefile should suffice.
Try devbr r46022.

Markus M

4

Hi,

2011/4/18 Markus Metz <markus.metz.giswork@googlemail.com>:

right, I would be happy to backport GRASS 7 Makefile system to GRASS
6. It would solve most of problems, make backporting easier. We just
need to extend Makefile system in GRASS 7 to support Bash scripts.
What do you think about that?

"just" ? I remember Glynn had objections against both python and shell
script support in the Makefile system.

AFAIR Glynn noted that it would be a little bit hard or tricky, but
possible (?) Anyway I think that Makefile system in GRASS 7 should
support at least Bash scripts (beside default Python).

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

5

On Mon, Apr 18, 2011 at 12:44 PM, Martin Landa <landa.martin@gmail.com> wrote:

Hi,

2011/4/18 Markus Metz <markus.metz.giswork@googlemail.com>:

right, I would be happy to backport GRASS 7 Makefile system to GRASS
6. It would solve most of problems, make backporting easier. We just
need to extend Makefile system in GRASS 7 to support Bash scripts.
What do you think about that?

"just" ? I remember Glynn had objections against both python and shell
script support in the Makefile system.

AFAIR Glynn noted that it would be a little bit hard or tricky, but
possible (?) Anyway I think that Makefile system in GRASS 7 should
support at least Bash scripts (beside default Python).

Hm, that is a discussion about the scripting language being used in
trunk/scripts. But then why where all these shell scripts converted to
python? Anyway, I am happily using my own shell scripts with GRASS 7,
IOW, for GRASS 7 I do not see a need to support shell scripts in the
Makefile system, apart from shell scripts in addons that can not
easily be installed via g.extension, although manually copying them to
the script folder of the GRASS 7 installation works (for me).

Markus M

6

Martin Landa wrote:

right, I would be happy to backport GRASS 7 Makefile system to GRASS
6. It would solve most of problems, make backporting easier. We just
need to extend Makefile system in GRASS 7 to support Bash scripts.
What do you think about that?

FWIW, I feel very strongly that shell-script support should be limited
to the backport. 7.0's build system should not support shell scripts
in any shape or form, and a 7.0 installation should not include any
shell scripts. The source tree *may* include shell scripts for use
during the build process (we can't realistically eliminate the shell
requirement from the build process, as Makefiles revolve around shell
commands), or for test cases, or as developer-oriented utilities.

Interactive shells are almost[1] the worst programming languages ever
created. Practically everything required for "real" programming has
been compromised in order to make the simplest cases require fewer
keystrokes. The only reason for using them is that the interpreter
(/bin/sh on Unix, cmd.exe on Windows) is guaranteed to be present. But
for cross-platform code, they don't even have this minimal benefit.

[1] The only exceptions are "joke" languages such as brainfuck or
whitespace.

In terms of the technicalities of supporting both shell scripts and
Python scripts in the build system, that isn't particularly difficult.
The easiest approach is to have e.g. ShScript.make and PyScript.make
instead of a single Script.make file.

For a shell script, the script's Makefile sets PGM to the name of the
script, and that will be the name of both the source file and the
installed file. On Windows, a batch file must also be created to run
the script (relying upon file associations is probably unrealistic).
If you're not using an English-language locale, you lose (due to the
ANSI/OEM codepage issue).

For a Python script, the source file is $(PGM).py and the installed
file is $(PGM) on Unix and $(PGM).py on Windows. No batch file is
required, but the ".py" extension must be registered (which means that
Python must be *installed* on the system; the GRASS installer must not
attempt to fudge this) and included in %PATHEXT% (this can be dealt
with by the GRASS startup if necessary).

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