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

[Glynn Clements]

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 at gclements.plus.com>