[GRASS5] 5.3.0 release

[Markus Neteler]

Hi Wolfgang

On Sat, Jul 19, 2003 at 05:35:36PM +0200, Wolfgang Lueck wrote:
> Hi Paul
> I understand your arguments and find them valid. Creating an automatic
> install script should receive priorety. This is an issue I have raised
> at numerous occasions but developers dont want to spend time on it as
> they receive little benefit from it.

This is not really true - I have a script which downloads GDAL,
installs it locally, downloads GRASS and generates a package
including GDAL. This could be easily extended to also download
and compile PROJ4.
I have posted that a few times and the automated GRASS 5.1
compilation every Saturday morning is using that script.
Just ask and you can have it :-)
To improve it to be robust, platform independent etc were
a good idea.

> Its much more exiting implementing
> new features. Unfortunately I come from the applied natural sciences
> (forestry) and have limited programming skills, but Im getting there. 
> I would like to spend my efforts on implementing several image
> manipulation / analysis features. Mabe the install script is something I
> should look at in future but will have to learn alot on the way and this
> will take time.

You can fetch the scrip (no warranty that it works for you) here:
http://mpa.itc.it/markus/useful/
->  build_grass50binaries.sh

The last GRAS 5.0.2 linux binaries were created using this script.
Be sure to go through it before using, there are some switches
to define if the CVS sources should be downloaded or only updated.

Cheers

 Markus

> Greetings Wolfgang
> 
> On Sat, 2003-07-19 at 12:44, Paul Kelly wrote:
> > Hello Wolfgang
> > 
> > On 19 Jul 2003, Wolfgang Lueck wrote:
> > 
> > > You realise that this is an additional installation hurdle for new
> > > users. 
> > 
> > I find it hard to disagree with you as this used to be my opinion as well.
> > Obviously this is true, although some users might have PROJ installed
> > already. So I will try and describe what has caused me to change my
> > opinion more recently.
> > 
> > Most important probably is that I can now compile an external PROJ.4 on
> > my system. When I first tried (version 4.4.5 I think) I couldn't get it to
> > compile on SGI/IRIX, so I relied on the internal GRASS copy then. But the
> > more recent PROJ versions I have had no problem with. It is very quick and
> > simple to install
> > 
> > tar xvzf proj-4.4.7.tar.gz
> > cd proj-4.4.7
> > ./configure
> > make
> > make install
> > 
> > and then you also have the cs2cs program to reproject points, which is
> > very useful.
> > 
> > We can put instructions on the website for how to do this, also for
> > checking that the directory where libproj.so is installed is in
> > /etc/ld.so.conf on Linux or in LD_LIBRARY_PATH.
> > 
> > > Do you feel that your user base is big enough and that your users
> > > are capable of installing all dependency packages on their own? Remember
> > > not all users are developers or really Linux / UNIX literate. 
> > 
> > In fairness, if a user is not Unix literate, they are not going to get
> > much out of GRASS, or certainly not use it to anywhere near its full
> > potential.
> > 
> > > I just see all those queries coming in as soon as this happens. There are 
> > > enough as there are with postgres, tcltk versions, and ODBC whose libraries
> > > residing in different locations depending on version and distribution.
> > 
> > I know this is not really your point but PROJ.4 is a lot smaller and
> > simpler to install than those other things. Tcl/Tk can take an hour to
> > compile and install; PROJ is just 5 minutes, or less on a fast machine. I
> > wouldn't even try installing postgres and ODBC from source. 
> > 
> > I suspect most queries would come from using an out-of-date version of
> > PROJ (this has been the case so far). I will try looking at getting the
> > configure script to check the version and refuse to continue if it is
> > older than 4.4.6.
> > 
> > > It might be trivial for you developers but certainly not for the users.
> > > Well If you go the route of removing PROJ and GDAL from the main
> > 
> > N.B. GDAL isn't contained in the GRASS sources. The change I was proposing
> > only means GDAL must be installed before compiling r.in.gdal if you want
> > to use it, rather than adding it as an afterthought. I suspect (have no
> > proof though) that the gdalbridge mechanism whereby you can compile GRASS
> > without GDAL and then install it afterwards is sometimes causing
> > segmentation faults with r.in.gdal because the gdalbridge code may be out
> > of date---this highlights an advantage of separating out things that are
> > maintained externally from GRASS.
> > 
> > > sources, we should consider setting up a package containing all
> > > ancillary code and packages. Even if it is a bit outdated, this might
> > > proove extremely valuable for Newbie's. These ancillary packages might
> > 
> > Yes, but installing these packages wouldn't be any less bother than
> > installing the latest version. I thought the point was that with the PROJ
> > built into GRASS the user didn't have to worry about installing it
> > separately. When PROJ was not being actively maintained for a few years it
> > was probably a good idea to keep a copy inside GRASS for a while, but now
> > that it is being maintained again and continuously changing it is just
> > messy having different versions around and trying to keep them up-to-date.
> > 
> > > be things like R, Gstats, alternate GUI's such as QGIS or QGRASS dwg
> > > import module etz. I still think that the biggest problem GRASS has is
> > > the steep learning curve which starts with its installation and
> > > configuration.  I frequently have to install the package for fellow GIS
> > > / RS users. 
> > 
> > What about writing a script that would automatically download the
> > latest versions of the packages from their respective ftp sites, gunzip,
> > untar, configure with the correct switches for use with GRASS, compile and
> > install them all before the main GRASS compilation?
> > 
> > Looks like there are two main reasons for having a separate PROJ:
> > 
> > 1) Less developer effort maintaining separate copies and user can take
> > advantage of latest PROJ capabilities without having to update GRASS.
> > 
> > 2) Requires much less space; src/libes/proj directory in GRASS was several
> > megabytes and all the projection code was compiled into a static library
> > and linked into every module that uses projection. This makes the binaries
> > much bigger as well. GRASS 5.1 (to be GRASS 5.7.x) uses shared libaries
> > and the compiled binaries take a tiny amount of space compared to GRASS
> > 5.0
> > 
> > 3) It appears to me generally the way things are done with most Free
> > software, i.e. all the packages depend on others which have to be
> > installed first. GRASS didn't used to be like that and is slowly evolving.
> > 
> > Definitely a script to download and install pre-requisite packages as a
> > pre-install step to GRASS might be a nice idea...
> > 
> > Paul
> > 
> > 
> 
> _______________________________________________
> grass5 mailing list
> grass5 at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5

-- 
Markus Neteler     <neteler at itc.it>       http://mpa.itc.it
ITC-irst, Istituto per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18        -       38050 Povo (Trento), Italy