[GRASS-dev] WinGRASS Wiki Hacking

Marco Pasetti marco.pasetti at alice.it
Sat Jun 21 11:35:00 EDT 2008


Hi Paul,

> I don't think it should be labour intensive - it should be able to be 
> scripted and run automatically. That said, I haven't got round to doing it 
> either. But deleting all mention of it will discourage other people from 
> helping with it.

Yes, it's not actually a labour intensive task. I just need to do it and 
upload the binaries to Markus (and write down few lines in the WinGRASS 
readme).
I'm doing my last university exams now, so sometimes "simple things" seem to 
me as "time expensive", when actually they aren't (ah... student anxiety!!)

> I think there are a few reasons for keeping it. People might want to try 
> old versions to see what is improved, or they might not have the bandwidth 
> to download the monolithic installer, or they just might not like 
> monolithic installers and prefer to run GRASS as a trial where it does not 
> affect anything else on their system.

actually the current WinGRASS installer just adds some entries to the 
registry and links to the Desktop and The StartMenu folder.
while, about the bandwith, yes, I could prepare a simple tar.gz with only 
the grass binaries, to use along the already distributed GRASS MSYS 
environment tar.gz
...we could do as follows: prepare a "complete" SVN development installer, 
with all included (GRASS + dependencies), and then a "simple" SVN weekly 
snaposhot GRASS installer that contains only the GRASS binaryes and 
automatically installs those binaries in the "right place" reading the 
needed paths into the registry.

>monolithic
> installer and zipped binaries that can be run directly and don't require 
> installation

yes we could, but I don't know id we have so much space to use on the osgeo 
server (Markus?). This said, the installer creates 3 specific files during 
the installation (grass.bat, grass and .grassrc6), to fits the specif user 
configuration (basically the install dir path); simple binaries will not 
work "alone"... (even if they just need few line hacking in those files...)

> Also at some stage I think we need to update the "Compiling by yourself" 
> section to reflect that lots of the libraries are available from Gnuwin32 
> at http://gnuwin32.sourceforge.net/.

I'm afraid to come again on this topic, but I definetely checked that many 
binaries from the GNUWin32 project don't work as expected when building 
GRASS or other libraries. I can give you many examples: zlib, libpng, 
libtiff, libjpeg and others... I don't know why, but when I tried to build 
both GDAL and GRASS with them, they failed... while if I use my builds (from 
source) they compile! I'm not stubborn, nor I want to reinvent the wheel 
each time, but I tried... and sometimes they don't work! That's my work 
procedure: try prebuilt libs first! if they don't work as expected, try 
build them from source.... and if I say in my guide to build from source 
instead of use prebuilt binaries, there's actually a reason...

>And definitely mention that Tcl/Tk can be compiled from source and 
>Activestate Tcl isn't a strict requirement.

yes, I think that we should deeply modify this section. First of all I 
should move my building guide into /mswindows/native/ and then refer to 
that.

> "Nothing known" for XP/2000 issues sounds a little optimistic!

yes, it's a lot optimistic! But I guess that the person who wrote that 
lines, intended that there are no specific issues with XP... while there are 
many with Windows in general...

> Re the FFmpeg linking problem I think Glynn said on the list that he had 
> fixed it in SVN.

I suppose that Glynn fixed the libavutil check in the configure, and not the 
gcc issue in the makefile. But I just suppose...

> I had never heard of OSGeo4W (not sure if I like the name) - looks like it 
> could be intersting.

I'm actually working with it; but there are still many opened issues about 
it (the main is that they use VS to build binaries)

> P.S. Marco I'm not suggesting you fix all these things or that we need an 
> answer to them! Just that they might be useful for us to consider.

Don't worry, I need this kind of mails :-)

Thanks for all; now I must come back to my books :-(

Marco 



More information about the grass-dev mailing list