[GRASS-dev] Re: [bug #5218] (grass) wingrass: creating new location from startup screen with projection values fails

Michael Barton via RT wrote:

This won't work because it requires an interactive xterm. This is not
currently available in wingrass, though I think I remember some discussion
by Glynn suggesting that it might (or might not) be possible to compile
wingrass in such a way as to make this and similar functions work.

But there is a terminal, but it fails before getting to the screen where you define the location extension. So must be something about how this screen is constructed.

If I do not use Huidae's grass.bat (which actually launches cmd.exe as terminal), but I launch grass from a Msys teminal (after setting path to include postgresql/bin and GRASS_WISH=wish84), and I then try to launch the location creation with projection values, it fails immediately, with the following error:

Cleaning up temporary files.....
Starting GRASS ...
'clear' n'est pas reconnu en tant que commande interne
ou externe, un programme ex‚cutable ou un fichier de commandes.
LINES value must be >= 2 and <= -9808: got 1
initscr(): LINES=1 COLS=1: too small.

Moritz

On Thu, Oct 19, 2006 at 10:17:13AM +0200, Moritz Lennert wrote:

Michael Barton via RT wrote:
>This won't work because it requires an interactive xterm. This is not
>currently available in wingrass, though I think I remember some discussion
>by Glynn suggesting that it might (or might not) be possible to compile
>wingrass in such a way as to make this and similar functions work.

But there is a terminal, but it fails before getting to the screen where you
define the location extension. So must be something about how this screen is
constructed.

If I do not use Huidae's grass.bat (which actually launches cmd.exe as
terminal), but I launch grass from a Msys teminal (after setting path to
include postgresql/bin and GRASS_WISH=wish84), and I then try to launch the
location creation with projection values, it fails immediately, with the
following error:

Cleaning up temporary files.....
Starting GRASS ...
'clear' n'est pas reconnu en tant que commande interne
ou externe, un programme ex‚cutable ou un fichier de commandes.
LINES value must be >= 2 and <= -9808: got 1
initscr(): LINES=1 COLS=1: too small.

Moritz

Programs compiled with the pdcurses library do not work with the MSys
terminal because of the above-mentioned problem. That's why I used
cmd.exe for grass.bat. If NO modules called from gis.m use the curses
library, rxvt.exe (MSys terminal) would be a better option because it
opens std* channels extensively used in TclTk codes.

I cannot decide which one is better between cmd.exe and rxvt.exe :-(.
Any idea?

Huidae

Huidae Cho wrote:

> >This won't work because it requires an interactive xterm. This is not
> >currently available in wingrass, though I think I remember some discussion
> >by Glynn suggesting that it might (or might not) be possible to compile
> >wingrass in such a way as to make this and similar functions work.
>
> But there is a terminal, but it fails before getting to the screen where you
> define the location extension. So must be something about how this screen is
> constructed.
>
> If I do not use Huidae's grass.bat (which actually launches cmd.exe as
> terminal), but I launch grass from a Msys teminal (after setting path to
> include postgresql/bin and GRASS_WISH=wish84), and I then try to launch the
> location creation with projection values, it fails immediately, with the
> following error:
>
> Cleaning up temporary files.....
> Starting GRASS ...
> 'clear' n'est pas reconnu en tant que commande interne
> ou externe, un programme ex?cutable ou un fichier de commandes.
> LINES value must be >= 2 and <= -9808: got 1
> initscr(): LINES=1 COLS=1: too small.

Programs compiled with the pdcurses library do not work with the MSys
terminal because of the above-mentioned problem. That's why I used
cmd.exe for grass.bat. If NO modules called from gis.m use the curses
library, rxvt.exe (MSys terminal) would be a better option because it
opens std* channels extensively used in TclTk codes.

I cannot decide which one is better between cmd.exe and rxvt.exe :-(.
Any idea?

cmd.exe is a shell (aka command interpreter), akin to bash or csh.
rxvt is a terminal emulator, akin to the Windows console. You can run
cmd.exe in rxvt, and you can run bash in the Windows console.

I don't see any real benefit to using rxvt on Windows NT/2K/XP. On
95/98/ME, the "DOS box" was somewhat limited (e.g. no scrollback,
restrictions on window size, 8086-compatibility environment, etc), so
there were some advantages to using rxvt there.

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

On Thu, October 19, 2006 14:45, Glynn Clements wrote:

Huidae Cho wrote:

> >This won't work because it requires an interactive xterm. This is

not

> >currently available in wingrass, though I think I remember some
discussion
> >by Glynn suggesting that it might (or might not) be possible to
compile
> >wingrass in such a way as to make this and similar functions work.
>
> But there is a terminal, but it fails before getting to the screen
where you
> define the location extension. So must be something about how this
screen is
> constructed.
>
> If I do not use Huidae's grass.bat (which actually launches cmd.exe

as

> terminal), but I launch grass from a Msys teminal (after setting path
to
> include postgresql/bin and GRASS_WISH=wish84), and I then try to
launch the
> location creation with projection values, it fails immediately, with
the
> following error:
>
> Cleaning up temporary files.....
> Starting GRASS ...
> 'clear' n'est pas reconnu en tant que commande interne
> ou externe, un programme ex?cutable ou un fichier de commandes. LINES value must be >= 2 and <= -9808: got 1
> initscr(): LINES=1 COLS=1: too small.
Programs compiled with the pdcurses library do not work with the MSys terminal because of the above-mentioned problem. That's why I used cmd.exe for grass.bat. If NO modules called from gis.m use the curses library, rxvt.exe (MSys terminal) would be a better option because it opens std* channels extensively used in TclTk codes.
I cannot decide which one is better between cmd.exe and rxvt.exe :-(. Any idea?

cmd.exe is a shell (aka command interpreter), akin to bash or csh. rxvt is a terminal emulator, akin to the Windows console. You can run cmd.exe in rxvt, and you can run bash in the Windows console.
I don't see any real benefit to using rxvt on Windows NT/2K/XP. On 95/98/ME, the "DOS box" was somewhat limited (e.g. no scrollback, restrictions on window size, 8086-compatibility environment, etc), so there were some advantages to using rxvt there.

So, IIUC, this should work with cmd.exe which allows pdcurses code, but
it doesn't and fails with:

The procedure crashes after entering
the one-line description of the new location with an error message: "the syntax of the command is not correct. LOCATION (test) NOT created"

(translated

from French).

So, if this is not a pdcurses issue, what could be the problem ?

Also, if you look at bug 5216, you can see that if I use the msys
terminal directly, I can create a new location based on a georeferenced
file, but I cannot using cmd.exe via grass.bat. What would explain this ?

Moritz

Moritz Lennert wrote:

So, IIUC, this should work with cmd.exe which allows pdcurses code, but
it doesn't and fails with:

> The procedure crashes after entering

> the one-line description of the new location with an error
> message: "the syntax of the command is not correct. LOCATION (test)
> NOT created" (translated from French).

So, if this is not a pdcurses issue, what could be the problem ?

make_location() uses system() with Unix commands:

    sprintf (buf, "mkdir '%s'/'%s'", gisdbase, location_name);
    if(system(buf)) return 0;
    sprintf (buf, "mkdir '%s'/'%s'/'%s'", gisdbase, location_name, mapset);
    if(system(buf)) return 0;

[snip]

    sprintf (buf, "echo '%s' > '%s'/'%s'/'%s'/MYNAME", myname, gisdbase, location_name, mapset);
    system(buf);

On a native Windows version, system() will use cmd.exe to execute
commands, not /bin/sh.

Windows has native versions of mkdir and echo. The native mkdir won't
like being passed Unix filenames, as it treats / as indicating
options:

  C:\>mkdir /foo
  The syntax of the command is incorrect.

Fortunately, this bug shoud be quite simple to fix: use the mkdir()
function rather than using system() to run the mkdir command. Could
someone try the attached patch?

Unfortunately, GRASS has a lot of this sort of stuff - using system()
to run commands rather than using functions; probably because the
author knew about the command but didn't know about the function. I've
even seen system("rm ...") used to delete files.

Finding (and fixing) all of the Unix-specific system() calls will be a
large part of getting a native Windows version of GRASS to work.

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

(attachments)

make_location.diff (1.07 KB)

Glynn Clements wrote:

Moritz Lennert wrote:

> So, IIUC, this should work with cmd.exe which allows pdcurses code, but
> it doesn't and fails with:
>
> > The procedure crashes after entering

> > the one-line description of the new location with an error
> > message: "the syntax of the command is not correct. LOCATION (test)
> > NOT created" (translated from French).
>
> So, if this is not a pdcurses issue, what could be the problem ?

make_location() uses system() with Unix commands:

    sprintf (buf, "mkdir '%s'/'%s'", gisdbase, location_name);
    if(system(buf)) return 0;
    sprintf (buf, "mkdir '%s'/'%s'/'%s'", gisdbase, location_name, mapset);
    if(system(buf)) return 0;

[snip]

    sprintf (buf, "echo '%s' > '%s'/'%s'/'%s'/MYNAME", myname, gisdbase, location_name, mapset);
    system(buf);

On a native Windows version, system() will use cmd.exe to execute
commands, not /bin/sh.

Windows has native versions of mkdir and echo. The native mkdir won't
like being passed Unix filenames, as it treats / as indicating
options:

  C:\>mkdir /foo
  The syntax of the command is incorrect.

Fortunately, this bug shoud be quite simple to fix: use the mkdir()
function rather than using system() to run the mkdir command. Could
someone try the attached patch?

Unfortunately, GRASS has a lot of this sort of stuff - using system()
to run commands rather than using functions; probably because the
author knew about the command but didn't know about the function. I've
even seen system("rm ...") used to delete files.

Finding (and fixing) all of the Unix-specific system() calls will be a
large part of getting a native Windows version of GRASS to work.

grass63$ grep -rI mkdir * | grep sprintf

gem/reg_entries.c: sprintf ( str, "mkdir --verbose %s/etc/dm/gem-entries ; cp -vf ../entries-gisman %s/etc/dm/gem-entries/%s ; \
gem/reg_entries.c: sprintf ( str, "mkdir %s/etc/dm/gem-entries &> %s ; cp -f ../entries-gisman %s/etc/dm/gem-entries/%s &> %s ; \
gem/reg_entries.c: sprintf ( str, "mkdir --verbose -p %s/etc/gm/Xtns ; cp -fv ../entries-gisman2 %s/etc/gm/Xtns/%s.gem ; ",
gem/reg_entries.c: sprintf ( str, "mkdir -p %s/etc/gm/Xtns ; cp -f ../entries-gisman2 %s/etc/gm/Xtns/%s.gem ; ",
lib/init/mke_loc.c: sprintf (buf, "mkdir '%s'/'%s'", gisdbase, location_name);
lib/init/mke_loc.c: sprintf (buf, "mkdir '%s'/'%s'/'%s'", gisdbase, location_name, mapset);
lib/init/mke_mapset.c: sprintf(buffer,"mkdir '%s'/'%s'",location, mapset) ;

$ grep -rI mkdir * | grep system

raster/r.le/r.le.setup/main.c: G_system("mkdir r.le.para");
raster/r.le/r.le.patch/main.c: G_system("mkdir r.le.out");
raster/r.le/r.le.pixel/main.c: G_system("mkdir r.le.out");

Hamish

Glynn Clements wrote:

Windows has native versions of mkdir and echo. The native mkdir won't
like being passed Unix filenames, as it treats / as indicating
options:

  C:\>mkdir /foo
  The syntax of the command is incorrect.

Fortunately, this bug shoud be quite simple to fix: use the mkdir()
function rather than using system() to run the mkdir command. Could
someone try the attached patch?

Unfortunately, GRASS has a lot of this sort of stuff - using system()
to run commands rather than using functions; probably because the
author knew about the command but didn't know about the function. I've
even seen system("rm ...") used to delete files.

Finding (and fixing) all of the Unix-specific system() calls will be a
large part of getting a native Windows version of GRASS to work.

here are some more:

lib/vask/V_init.c: system("clear"); /* this is a kludge - xterm has problems
lib/fonts/for_grass/try.c: system ("cd fonts; ls *.hmp | sed 's/.hmp//' | fmt");
lib/fonts/for_grass/fontmap.c: system ("cd ../fonts; ls *.hmp | sed 's/.hmp//' | fmt");
raster/r.out.mpeg/main.c: sprintf(cmd, "cd %s; \\ls %s >> %s 2> /dev/null",
visualization/xganim/main.c: sprintf(cmd, "cd %s; \\ls %s >> %s 2> /dev/null", path, wildarg, tfile);
general/g.mapsets/main_cmd.c: sprintf (command, "ls -C %s/%s 1>&2", G_gisdbase(), G_location());
general/g.mapsets/main_cmd.c: sprintf (command, "ls -C %s/%s 1>&2", G_gisdbase(), G_location());
imagery/i.ortho.photo/photo.target/ask_target.c: sprintf (buf, "ls -C %s\n", G_gisdbase());
imagery/i.ortho.photo/photo.target/ask_target.c: sprintf (buf, "ls %s/%s", G_gisdbase(), G_location());
lib/init/set_data.c: sprintf(buf, "ls -C '%s'", gisdbase) ;
lib/init/set_data.c: sprintf (buf, "ls '%s'", location);

Hamish

------- from previous post ----------

grass63$ grep -rI mkdir * | grep sprintf

gem/reg_entries.c: sprintf ( str, "mkdir --verbose %s/etc/dm/gem-entries ; cp -vf ../entries-gisman %s/etc/dm/gem-entries/%s ; \
gem/reg_entries.c: sprintf ( str, "mkdir %s/etc/dm/gem-entries &> %s ; cp -f ../entries-gisman %s/etc/dm/gem-entries/%s &> %s ; \
gem/reg_entries.c: sprintf ( str, "mkdir --verbose -p %s/etc/gm/Xtns ; cp -fv ../entries-gisman2 %s/etc/gm/Xtns/%s.gem ; ",
gem/reg_entries.c: sprintf ( str, "mkdir -p %s/etc/gm/Xtns ; cp -f ../entries-gisman2 %s/etc/gm/Xtns/%s.gem ; ",
lib/init/mke_loc.c: sprintf (buf, "mkdir '%s'/'%s'", gisdbase, location_name);
lib/init/mke_loc.c: sprintf (buf, "mkdir '%s'/'%s'/'%s'", gisdbase, location_name, mapset);
lib/init/mke_mapset.c: sprintf(buffer,"mkdir '%s'/'%s'",location, mapset) ;

$ grep -rI mkdir * | grep system

raster/r.le/r.le.setup/main.c: G_system("mkdir r.le.para");
raster/r.le/r.le.patch/main.c: G_system("mkdir r.le.out");
raster/r.le/r.le.pixel/main.c: G_system("mkdir r.le.out");

Glynn Clements wrote:

Unfortunately, GRASS has a lot of this sort of stuff - using system()
to run commands rather than using functions; probably because the
author knew about the command but didn't know about the function. I've
even seen system("rm ...") used to delete files.

Finding (and fixing) all of the Unix-specific system() calls will be a
large part of getting a native Windows version of GRASS to work.

Does MinGW provide "clear" for "cls"? I seem to remember someone
recently complaining about that,

grass63$ grep -rI clear * | grep system | cut -f1 -d: | uniq
lib/gis/clear_scrn.c
lib/vask/V_clear.c
lib/vask/V_init.c
raster/r.le/r.le.setup/mv_wind.c
raster/r.le/r.le.setup/ask_group.c
raster/r.le/r.le.setup/sample.c
raster/r.le/r.le.setup/setup.c
raster/r.le/r.le.trace/main.c
raster/r.coin/inter.c
vector/v.transform/creat_trans.c

Hamish

Hamish wrote:

> Unfortunately, GRASS has a lot of this sort of stuff - using system()
> to run commands rather than using functions; probably because the
> author knew about the command but didn't know about the function. I've
> even seen system("rm ...") used to delete files.
>
> Finding (and fixing) all of the Unix-specific system() calls will be a
> large part of getting a native Windows version of GRASS to work.

grass63$ grep -rI mkdir * | grep sprintf

gem/reg_entries.c: sprintf ( str, "mkdir --verbose %s/etc/dm/gem-entries ; cp -vf ../entries-gisman %s/etc/dm/gem-entries/%s ; \
gem/reg_entries.c: sprintf ( str, "mkdir %s/etc/dm/gem-entries &> %s ; cp -f ../entries-gisman %s/etc/dm/gem-entries/%s &> %s ; \
gem/reg_entries.c: sprintf ( str, "mkdir --verbose -p %s/etc/gm/Xtns ; cp -fv ../entries-gisman2 %s/etc/gm/Xtns/%s.gem ; ",
gem/reg_entries.c: sprintf ( str, "mkdir -p %s/etc/gm/Xtns ; cp -f ../entries-gisman2 %s/etc/gm/Xtns/%s.gem ; ",

GEM creates substantial scripts using sprintf(), then runs them using
"su -c ...". Ick. That isn't something which can easily be changed,
though.

lib/init/mke_loc.c: sprintf (buf, "mkdir '%s'/'%s'", gisdbase, location_name);
lib/init/mke_loc.c: sprintf (buf, "mkdir '%s'/'%s'/'%s'", gisdbase, location_name, mapset);
lib/init/mke_mapset.c: sprintf(buffer,"mkdir '%s'/'%s'",location, mapset) ;

mke_mapset.c can be changed likewise. Ironically, it already uses
mkdir() to create the dbf directory.

$ grep -rI mkdir * | grep system

raster/r.le/r.le.setup/main.c: G_system("mkdir r.le.para");
raster/r.le/r.le.patch/main.c: G_system("mkdir r.le.out");
raster/r.le/r.le.pixel/main.c: G_system("mkdir r.le.out");

Well, r.le is r.le; nothing surprises me there.

We should probably add a G_mkdir(), to save having to handle the
Windows mkdir() (which only takes one argument) in lots of different
files.

In any case, system("mkdir ...") is just the tip of the iceberg. I
count:

  function count

  system 52
  G_system 25
  popen 28
  G_popen 3

  total 108

I wouldn't be surprised if the majority of those calls have some kind
of portability issue.

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

Glynn Clements wrote:

Moritz Lennert wrote:

So, IIUC, this should work with cmd.exe which allows pdcurses code, but
it doesn't and fails with:

The procedure crashes after entering

the one-line description of the new location with an error
message: "the syntax of the command is not correct. LOCATION (test)
NOT created" (translated from French).

So, if this is not a pdcurses issue, what could be the problem ?

make_location() uses system() with Unix commands:

    sprintf (buf, "mkdir '%s'/'%s'", gisdbase, location_name);
    if(system(buf)) return 0;
    sprintf (buf, "mkdir '%s'/'%s'/'%s'", gisdbase, location_name, mapset);
    if(system(buf)) return 0;

[snip]

    sprintf (buf, "echo '%s' > '%s'/'%s'/'%s'/MYNAME", myname, gisdbase, location_name, mapset);
    system(buf);

On a native Windows version, system() will use cmd.exe to execute
commands, not /bin/sh.

Windows has native versions of mkdir and echo. The native mkdir won't
like being passed Unix filenames, as it treats / as indicating
options:

  C:\>mkdir /foo
  The syntax of the command is incorrect.

Fortunately, this bug shoud be quite simple to fix: use the mkdir()
function rather than using system() to run the mkdir command. Could
someone try the attached patch?

I am more than willing to do more extensive testing and also to work on some of the system calls you mention, but I what do I need for native compilation ? Or cross-compilation on debian for windows (never compiled anything on windows in my life :wink: ) ?

I will be very busy in the next 10 days, but after that I should have substantially more time for GRASS.

Moritz

Hamish wrote:

> Unfortunately, GRASS has a lot of this sort of stuff - using system()
> to run commands rather than using functions; probably because the
> author knew about the command but didn't know about the function. I've
> even seen system("rm ...") used to delete files.
>
> Finding (and fixing) all of the Unix-specific system() calls will be a
> large part of getting a native Windows version of GRASS to work.

Does MinGW provide "clear" for "cls"? I seem to remember someone
recently complaining about that,

grass63$ grep -rI clear * | grep system | cut -f1 -d: | uniq
lib/gis/clear_scrn.c

lib/vask/V_clear.c
lib/vask/V_init.c

V_init() uses the curses clear() function, although it also uses
system("clear"):

    system("clear"); /* this is a kludge - xterm has problems
       * it shows what was on the screen after
       * endwin is called in V_exit()
       */

Personally, I don't consider xterm's behaviour to be a problem.

V_clear() has the call commented out:

/* please leave this code commented out
  fflush(stdout);
  system("clear");
*/

Anything which uses curses should use the clear() function. Anything
which doesn't use curses probably shouldn't be trying to clear the
screen.

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

Moritz Lennert wrote:

> Fortunately, this bug shoud be quite simple to fix: use the mkdir()
> function rather than using system() to run the mkdir command. Could
> someone try the attached patch?

I am more than willing to do more extensive testing and also to work on
some of the system calls you mention, but I what do I need for native
compilation ? Or cross-compilation on debian for windows (never compiled
anything on windows in my life :wink: ) ?

Native compilation is probably easier.

For this, you need MinGW and MSys, including gcc, g++, binutils, flex,
bison, make, and pdcurses, all from:

http://www.mingw.org/download.shtml

You also need this version of the XDR library:

http://wiki.qgis.org/qgiswiki/BuildingWindowsBinaryOnLinux?action=AttachFile&do=get&target=xdr-4.0-mingw2.tar.gz

The above is a stripped-down version of the Sun RPC library, which
only includes the XDR [de]serialisation code, with the networking code
removed.

You will first need to build and install zlib, PNG, PROJ, GDAL and the
above XDR library. Then, building GRASS is similar to building it on
Linux, except that you need to disable most of the optional features
(including the use of shared libraries).

Aside: it might encourage more people to work on the Windows version
if the GRASS site contained binary versions of the necessary
libraries. Having to build XDR, PROJ, GDAL, zlib, PNG, Tcl/Tk and
possibly other stuff from source before you can start to compile GRASS
is a major nuisance.

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

On Wed, Oct 25, 2006 at 07:07:54PM +0100, Glynn Clements wrote:

Native compilation is probably easier.

For this, you need MinGW and MSys, including gcc, g++, binutils, flex,
bison, make, and pdcurses, all from:

I have taken liberty to copy this to the Wiki
http://grass.gdf-hannover.de/wiki/Compile_and_Install#MS-Windows.2Fnative

Aside: it might encourage more people to work on the Windows version
if the GRASS site contained binary versions of the necessary
libraries. Having to build XDR, PROJ, GDAL, zlib, PNG, Tcl/Tk and
possibly other stuff from source before you can start to compile GRASS
is a major nuisance.

I can easily upload them to the GRASS site if someone provides me
with these binary packages.

Markus

Glynn Clements wrote:

Moritz Lennert wrote:

Fortunately, this bug shoud be quite simple to fix: use the mkdir()
function rather than using system() to run the mkdir command. Could
someone try the attached patch?

I am more than willing to do more extensive testing and also to work on some of the system calls you mention, but I what do I need for native compilation ? Or cross-compilation on debian for windows (never compiled anything on windows in my life :wink: ) ?

Native compilation is probably easier.

For this, you need MinGW and MSys, including gcc, g++, binutils, flex,
bison, make, and pdcurses, all from:

http://www.mingw.org/download.shtml

You also need this version of the XDR library:

http://wiki.qgis.org/qgiswiki/BuildingWindowsBinaryOnLinux?action=AttachFile&do=get&target=xdr-4.0-mingw2.tar.gz

The above is a stripped-down version of the Sun RPC library, which
only includes the XDR [de]serialisation code, with the networking code
removed.

You will first need to build and install zlib, PNG, PROJ, GDAL and the
above XDR library. Then, building GRASS is similar to building it on
Linux, except that you need to disable most of the optional features
(including the use of shared libraries).

Thanks for the clear instructions.

Aside: it might encourage more people to work on the Windows version
if the GRASS site contained binary versions of the necessary
libraries. Having to build XDR, PROJ, GDAL, zlib, PNG, Tcl/Tk and
possibly other stuff from source before you can start to compile GRASS
is a major nuisance.

What about the packages installed by Huidae's installer:

http://prdownloads.sourceforge.net/g/gn/gnuwin32

(Huidae's inst_grass.bat downloads: libiconv-1.9.2-1 libpng-1.2.8 jpeg-6b-4 tiff-3.8.2-1 file-4.16-1 freetype-2.1.10 pdcurses-2.6 readline-5.0 gettext-0.14.4 zlib-1.2.3 zip-2.31)

Would I need the *-lib packages for compilation ?

For Tcl/Tk Huidae recommends, i.e.:

http://prdownloads.sourceforge.net/mingw/tcltk-8.4.1-1.exe?download

And Huidae provides:

fftw-2.1.5-1 gdal-1.3.2-1 geos-2.2.3-1 proj-4.4.9-1 sqlite-3.3.6-1 xdr-4.0-1

from http://geni.ath.cx/grass/

Isn't that enough ?

Moritz

Moritz Lennert wrote:

> Aside: it might encourage more people to work on the Windows version
> if the GRASS site contained binary versions of the necessary
> libraries. Having to build XDR, PROJ, GDAL, zlib, PNG, Tcl/Tk and
> possibly other stuff from source before you can start to compile GRASS
> is a major nuisance.

What about the packages installed by Huidae's installer:

http://prdownloads.sourceforge.net/g/gn/gnuwin32

(Huidae's inst_grass.bat downloads: libiconv-1.9.2-1 libpng-1.2.8
jpeg-6b-4 tiff-3.8.2-1 file-4.16-1 freetype-2.1.10 pdcurses-2.6
readline-5.0 gettext-0.14.4 zlib-1.2.3 zip-2.31)

Some of those should be optional, although most of them are useful (I
don't know about file and zip, though). If that version of zlib is
usable, we can use that rather than our own package.

Would I need the *-lib packages for compilation ?

Maybe. You need the header files for compilation, whereas you only
need DLLs for pre-compiled applications. If the packages are split,
then you will need both parts.

For Tcl/Tk Huidae recommends, i.e.:

http://prdownloads.sourceforge.net/mingw/tcltk-8.4.1-1.exe?download

Is that actually a *native* version, or does it include MinGW-isms?

And Huidae provides:

fftw-2.1.5-1 gdal-1.3.2-1 geos-2.2.3-1 proj-4.4.9-1 sqlite-3.3.6-1
xdr-4.0-1

from http://geni.ath.cx/grass/

Isn't that enough ?

If he provides usable packages (compiled libraries and headers), then
we should use those. However, I get a "forbidden" error for the above
URL, and I couldn't find individual packages from the main page.

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

On Thu, October 26, 2006 21:06, Glynn Clements wrote:

Moritz Lennert wrote:

> Aside: it might encourage more people to work on the Windows version
> if the GRASS site contained binary versions of the necessary
> libraries. Having to build XDR, PROJ, GDAL, zlib, PNG, Tcl/Tk and
> possibly other stuff from source before you can start to compile GRASS
> is a major nuisance.

What about the packages installed by Huidae's installer:

http://prdownloads.sourceforge.net/g/gn/gnuwin32

(Huidae's inst_grass.bat downloads: libiconv-1.9.2-1 libpng-1.2.8
jpeg-6b-4 tiff-3.8.2-1 file-4.16-1 freetype-2.1.10 pdcurses-2.6
readline-5.0 gettext-0.14.4 zlib-1.2.3 zip-2.31)

Some of those should be optional, although most of them are useful (I
don't know about file and zip, though). If that version of zlib is
usable, we can use that rather than our own package.

Would I need the *-lib packages for compilation ?

Maybe. You need the header files for compilation, whereas you only
need DLLs for pre-compiled applications. If the packages are split,
then you will need both parts.

mlennert@geog-pc40:~$ unzip -l freetype-2.0.1-bin.zip
Archive: freetype-2.0.1-bin.zip
freetype 2.0.1: binaries
   Length Date Time Name
  -------- ---- ---- ----
    790571 03-08-01 11:33 bin/libfreetype.dll
       995 03-21-01 19:11 contrib/freetype-2.0.1.README
        26 03-21-01 19:11 manifest/freetype-2.0.1-bin.ver
       122 03-21-01 19:11 manifest/freetype-2.0.1-bin.mft
  -------- -------
    791714 4 files
mlennert@geog-pc40:~$ unzip -l freetype-2.0.1-lib.zip
Archive: freetype-2.0.1-lib.zip
freetype 2.0.1: libraries
   Length Date Time Name
  -------- ---- ---- ----
    152685 12-01-00 00:08 include/freetype/freetype.h
      4043 12-01-00 00:08 include/freetype/ftbbox.h
     22183 12-01-00 00:08 include/freetype/ftcache.h
      8667 12-01-00 18:25 include/freetype/fterrors.h
      etc...

So it's both.

For Tcl/Tk Huidae recommends, i.e.:

http://prdownloads.sourceforge.net/mingw/tcltk-8.4.1-1.exe?download

Is that actually a *native* version, or does it include MinGW-isms?

Don't know. Huidae ?

And Huidae provides:

fftw-2.1.5-1 gdal-1.3.2-1 geos-2.2.3-1 proj-4.4.9-1 sqlite-3.3.6-1
xdr-4.0-1

from http://geni.ath.cx/grass/

Isn't that enough ?

If he provides usable packages (compiled libraries and headers), then
we should use those. However, I get a "forbidden" error for the above
URL, and I couldn't find individual packages from the main page.

They are available as http://geni.ath.cx/grass/fftw-2.1.5-1.zip etc.

Moritz

On Mon, Oct 30, 2006 at 05:23:45PM +0100, Moritz Lennert wrote:

On Thu, October 26, 2006 21:06, Glynn Clements wrote:
>Moritz Lennert wrote:
>>> Aside: it might encourage more people to work on the Windows version
>>> if the GRASS site contained binary versions of the necessary
>>> libraries. Having to build XDR, PROJ, GDAL, zlib, PNG, Tcl/Tk and
>>> possibly other stuff from source before you can start to compile GRASS
>>> is a major nuisance.
>>What about the packages installed by Huidae's installer:
>>http://prdownloads.sourceforge.net/g/gn/gnuwin32
>>(Huidae's inst_grass.bat downloads: libiconv-1.9.2-1 libpng-1.2.8
>>jpeg-6b-4 tiff-3.8.2-1 file-4.16-1 freetype-2.1.10 pdcurses-2.6
>>readline-5.0 gettext-0.14.4 zlib-1.2.3 zip-2.31)
>Some of those should be optional, although most of them are useful (I
>don't know about file and zip, though). If that version of zlib is
>usable, we can use that rather than our own package.
>>Would I need the *-lib packages for compilation ?
>Maybe. You need the header files for compilation, whereas you only
>need DLLs for pre-compiled applications. If the packages are split,
>then you will need both parts.

mlennert@geog-pc40:~$ unzip -l freetype-2.0.1-bin.zip
Archive: freetype-2.0.1-bin.zip
freetype 2.0.1: binaries
   Length Date Time Name
  -------- ---- ---- ----
    790571 03-08-01 11:33 bin/libfreetype.dll
       995 03-21-01 19:11 contrib/freetype-2.0.1.README
        26 03-21-01 19:11 manifest/freetype-2.0.1-bin.ver
       122 03-21-01 19:11 manifest/freetype-2.0.1-bin.mft
  -------- -------
    791714 4 files
mlennert@geog-pc40:~$ unzip -l freetype-2.0.1-lib.zip
Archive: freetype-2.0.1-lib.zip
freetype 2.0.1: libraries
   Length Date Time Name
  -------- ---- ---- ----
    152685 12-01-00 00:08 include/freetype/freetype.h
      4043 12-01-00 00:08 include/freetype/ftbbox.h
     22183 12-01-00 00:08 include/freetype/ftcache.h
      8667 12-01-00 18:25 include/freetype/fterrors.h
      etc...

So it's both.

>>For Tcl/Tk Huidae recommends, i.e.:
>>http://prdownloads.sourceforge.net/mingw/tcltk-8.4.1-1.exe?download
>Is that actually a *native* version, or does it include MinGW-isms?

Don't know. Huidae ?

AFAICT, the TclTk package is basically the same as one that is
distributed with Cygwin. That being said, it is a *native* version. No
POSIX path, no virtual mount (c:\msys => /), and etc. The reason why I
chose the MinGW version is just to reduce the number of sites the user
should visit to install required packages. The problem with Windows
TclTk (not just MinGW version) is that it has many known bugs such as
mouse event handling and bad return codes. See
http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status#TclTk_issues
for more detail.

>>And Huidae provides:
>>fftw-2.1.5-1 gdal-1.3.2-1 geos-2.2.3-1 proj-4.4.9-1 sqlite-3.3.6-1
>>xdr-4.0-1
>>from http://geni.ath.cx/grass/
>>Isn't that enough ?
>If he provides usable packages (compiled libraries and headers), then
>we should use those. However, I get a "forbidden" error for the above
>URL, and I couldn't find individual packages from the main page.

Directory browsing is forbidden, but access to an individual file is
allowed. I'm following what the web server admin decided to do.

Huidae

They are available as http://geni.ath.cx/grass/fftw-2.1.5-1.zip etc.

Moritz

Huidae Cho wrote:

> >>And Huidae provides:
> >>fftw-2.1.5-1 gdal-1.3.2-1 geos-2.2.3-1 proj-4.4.9-1 sqlite-3.3.6-1
> >>xdr-4.0-1
> >>from http://geni.ath.cx/grass/
> >>Isn't that enough ?
> >If he provides usable packages (compiled libraries and headers), then
> >we should use those. However, I get a "forbidden" error for the above
> >URL, and I couldn't find individual packages from the main page.

Directory browsing is forbidden, but access to an individual file is
allowed. I'm following what the web server admin decided to do.

Could you add links to the individual files somewhere?

In its current state, the native Windows version is arguably more
useful to developers wishing to help with the port than people who
actually want to use it, so an environment where you can compile GRASS
is more important than one where you can use it.

For that, a monolithic installer isn't necessarily the best approach.

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