[GRASS5] 5.3.0 release

[Wolfgang Lueck]

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. 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.

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
> 
>