[GRASS-dev] Wingrass and TclTk

[Benjamin Ducke]

Thanks, Glynn, for your detailed answers to this and
my other mail. That clarifies things a whole lot.

Re. the make problems: for the time being, I backported
some Makefiles from an older CVS copy that don't use
the "|" (this shows up right on my screen!) and all works fine
(except lib/forms/Makefile where I still copy around .h files
by hand) for now. It's all a bit of a nuisance but no critical
thing right now.

All other issues I reported earlier (concerning Tcl/Tk and NVIZ)
vanished once I followed Moritz' advise and started GRASS directly
w/o going through the MSYS terminal and shell.

Unfortunately, my current workload will not allow me to spend much
more time on WinGRASS for the next two weeks or so.
I hope I will be able to get back to it once GRASS 6.3.0 final is
released and polish things up.

Thanks again, everyone, for all the support in getting these things
figured out. I think a really smooth version of GRASS on Windows is
just a matter of a bit of fine-tuning (and getting the Win sockets
thing figured out) now.

Cheers,

Benjamin

Glynn Clements wrote:
> Benjamin Ducke wrote:
> 
>>> And you can run grass from within msys without integrating everying into
>>> the MSYS file structure. Just open msys, and run /c/grass/bin/grass63
>>> (IIRC, you need to change the definition of GISBASE in grass63 to
>>> correspond to msys syntax).
>> I don't think I understand this. That's what I have always been doing,
>> but that way, NVIZ crashes and module GUIs don't pop up.
>>
>> Anyway, I started my GRASS binaries using cmd.exe and grass63.bat and
>> everything works nicely: NVIZ runs and module forms work. So there is
>> nothing wrong with the binaries I made.
>> I guess I could live with that and skip the MSYS terminal window
>> altogether, however there are two annoyances:
>>
>> 1. If I want to start a shell script from cmd.exe, I need to specify the
>> path to sh.exe (or associate sh.exe with sh extensions in Windows,
>> but there are plenty of scripts w/o any extension).
> 
> That's why each shell script in $GISBASE/scripts gets a corresponding
> .bat file in $GISBASE/bin.
> 
>> 2. On startup, gis.m takes the input from CMD.exe and does not give it
>> back. It is however possible to quit gis.m, then restart it in the
>> background with gis.m & .
>>
>> Anyhow, editing grass63.bat by hand to suite the system dirs on every
>> machine is a real nuisance. It would be much more elegant via the MSYS
>> terminal window, where all DLLs and BINs are in scope the moment you
>> start it up (plus you get much better command line functionality).
> 
> Unfortunately, MSys isn't compatible with Windows. The programs (and
> the libraries which they use) need to use Windows functions, and those
> functions need to use Windows filenames. But Windows filenames don't
> work with MSys.
> 
> MSys is essentially an environment for cross-compilation. Programs
> compiled using MSys/MinGW will run under Windows, but they won't
> necessarily run under MSys itself. About the only things which *will*
> run under MSys itself are the MSys/MinGW tools, and some command-line
> programs which don't try to do anything non-trivial with filenames.
> 

-- 
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg