[GRASS-dev] WinGRASS Wiki Hacking

[Glynn Clements]

Marco Pasetti wrote:

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

Sooner or later, someone will need to bite the bullet and produce a
dependency-based installer, probably based upon Cygwin's.

The only question is how much time gets wasted on half-baked solutions
between now and then.

BTW, it might be a good idea to actually put a link to:

	http://www.webalice.it/marco.pasetti/grass/BuildFromSource.html

in an obvious place on the main GRASS website. I.e. on:

	http://grass.osgeo.org/devel/index.php

under "Compiling GRASS", in place of the link for cross-compiling
Windows binaries on Linux.

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

If you post to the list details of exactly what goes wrong when you
try to use the pre-compiled libraries, we might be able to help you.

Ideally, we shouldn't be recommending that people build from source
anything for which pre-compiled binaries are available.

I appreciate that you don't have an unlimited amount of time, and just
building from source may be quicker than figuring out how to use the
binaries, but ultimately using "official" binary releases is very much
preferable.

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

The OGSF Makefile didn't require any changes. The changes to configure
result in $(FFMPEGLIB) having -lavutil as well as -lavformat and
-lavcodec.

-- 
Glynn Clements <glynn at gclements.plus.com>