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
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
