[GRASS-dev] WinGRASS-6.3.0RC6 Self Installer

Marco_Pasetti · March 27, 2008, 4:46pm

Hi all,

I’m preparing WinGRASS-6.3.0RC6 Self Installer. In addition to RC6 build (naturally) I added some Windows registry keys (Name, Version and InstallPath), modified the script that creates grass63.bat (changing set PATH=%PATH%;… to set PATH=…;%PATH%) and rewrote README file.

I changed the README format from plain text to html in order to make the document more portable (since it is written according to w3C standards, with CSS embedded), more readable (since it is organized in sections with a table of contents) and more complete. I tried to follow all the notes and suggestions recently received from the list. Because it is an official document, I thought to propose it to the list before to pack it in the installer:

http://www.webalice.it/marco.pasetti/temp/README.html

Notes and suggestions about modifications, addings and removals in it will be highly appreciated.

Marco

mlennert · March 27, 2008, 5:21pm

On 27/03/08 17:46, marco.pasetti@alice.it wrote:

http://www.webalice.it/marco.pasetti/temp/README.html
Notes and suggestions about modifications, addings and removals in it will be highly appreciated.

- How to submit bugs ?

preferably here: http://trac.osgeo.org/grass/

but possibly on wingrass list

http://lists.osgeo.org/mailman/listinfo/grass-windows

- Maybe add the information about how to contact you (possibly via one of the mailing lists) ?

- Not about the document, but about the package:

1) ODBC and maybe MySQL might be good things to add. Especially the first, as this would potentially give access to Win-specific databases.

2) More a question to Glynn: I see r.terraflow is still missing. I guess this hasn't been backported to 6.3releasebranch ?

Once again: great job and many thanks !

Moritz

Glynn_Clements1 · March 27, 2008, 6:38pm

marco.pasetti@alice.it wrote:

Notes and suggestions about modifications, addings and removals in it
will be highly appreciated.

I would reduce the "missing modules" section to just:

  i.class
  i.ortho.photo
  i.points
  i.vpoints
  r.li
  r.terraflow

rather than listing the individual components of i.ortho.photo and
r.li.

BTW, should the r.terraflow portability fixes be back-ported to 6.3.0?

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

Glynn_Clements1 · March 27, 2008, 6:53pm

Moritz Lennert wrote:

1) ODBC and maybe MySQL might be good things to add. Especially the
first, as this would potentially give access to Win-specific databases.

Does the ODBC driver work with Windows ODBC?

2) More a question to Glynn: I see r.terraflow is still missing. I guess
this hasn't been backported to 6.3releasebranch ?

No, not yet.

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

neteler · March 27, 2008, 9:07pm

On Thu, Mar 27, 2008 at 7:53 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:

> 2) More a question to Glynn: I see r.terraflow is still missing. I guess
> this hasn't been backported to 6.3releasebranch ?

No, not yet.

Now yes:
http://trac.osgeo.org/grass/changeset/30767

Markus

mlennert · March 27, 2008, 9:21pm

On Thu, March 27, 2008 19:53, Glynn Clements wrote:

Moritz Lennert wrote:

1) ODBC and maybe MySQL might be good things to add. Especially the
first, as this would potentially give access to Win-specific databases.

Does the ODBC driver work with Windows ODBC?

Oh, I just assumed it would, but I imagine it would have to be compiled
against a windows odbc.h ? Or is the API equivalent between unixodbc and
win odbc ?

2) More a question to Glynn: I see r.terraflow is still missing. I guess
this hasn't been backported to 6.3releasebranch ?

No, not yet.

Do you feel it is premature to have them in the 6.3 release ? I'm afraid
not many people are going to test if we don't put them in a release.

Moritz

Marco_Pasetti · March 27, 2008, 9:50pm

Hi Moritz,

ODBC and maybe MySQL might be good things to add

They are actually in my wish list, along with jpeg support, FFMPEG, xerces
and some other things.
I just need a day of 48 hours ... But I think that waiting for some
months more until I'll take my degree will be enough!

Marco

-----Messaggio originale-----
Da: Moritz Lennert [mailto:mlennert@club.worldonline.be]
Inviato: giovedì 27 marzo 2008 18.22
A: marco.pasetti@alice.it
Cc: grass-dev@lists.osgeo.org; Glynn Clements
Oggetto: Re: [GRASS-dev] WinGRASS-6.3.0RC6 Self Installer

On 27/03/08 17:46, marco.pasetti@alice.it wrote:

http://www.webalice.it/marco.pasetti/temp/README.html

Notes and suggestions about modifications, addings and removals in it
will be highly appreciated.

- How to submit bugs ?

preferably here: http://trac.osgeo.org/grass/

but possibly on wingrass list

http://lists.osgeo.org/mailman/listinfo/grass-windows

- Maybe add the information about how to contact you (possibly via one of
the mailing lists) ?

- Not about the document, but about the package:

1) ODBC and maybe MySQL might be good things to add. Especially the first,
as this would potentially give access to Win-specific databases.

2) More a question to Glynn: I see r.terraflow is still missing. I guess
this hasn't been backported to 6.3releasebranch ?

Once again: great job and many thanks !

Moritz

Glynn_Clements1 · March 27, 2008, 11:51pm

Moritz Lennert wrote:

>> 1) ODBC and maybe MySQL might be good things to add. Especially the
>> first, as this would potentially give access to Win-specific databases.
>
> Does the ODBC driver work with Windows ODBC?

Oh, I just assumed it would, but I imagine it would have to be compiled
against a windows odbc.h ? Or is the API equivalent between unixodbc and
win odbc ?

AFAICT, the API should be consistent, although there may be other
issues, e.g. compilation and linking switches. There's also the issue
of whether the driver has ever been tested on Windows or with common
Windows databases.

>> 2) More a question to Glynn: I see r.terraflow is still missing. I guess
>> this hasn't been backported to 6.3releasebranch ?
>
> No, not yet.

Do you feel it is premature to have them in the 6.3 release ? I'm afraid
not many people are going to test if we don't put them in a release.

It's a moot point now that Markus has back-ported the changes, but
they should be safe for inclusion.

The Unix-isms which had to be worked around are (AFAICT) all in
"peripheral" functionality, i.e. monitoring resource (CPU, memory)
usage.

Most of the changes were essentially:

  #ifdef __MINGW32__
  <stub definitions>
  #else
  <real definitions>
  #endif

On Unix, the changes shouldn't have any effect. On Windows, the worst
that can happen is that it doesn't work (although it should at least
compile now), although it's more likely to just be that the resource
statistics will be inaccurate (e.g. memory usage reported as zero, CPU
usage measured in whole seconds rather than microseconds).

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

Glynn_Clements1 · March 28, 2008, 12:03am

Marco Pasetti wrote:

>ODBC and maybe MySQL might be good things to add

They are actually in my wish list, along with jpeg support, FFMPEG, xerces
and some other things.

JPEG support doesn't actually mean anything.

None of the Makefiles use the JPEG variables (JPEGLIB, JPEGLIBPATH and
JPEGINCPATH).

The configure script uses the variables when testing for the TIFF
library, but that only matters if the TIFF library was built with JPEG
support but it requires specific switches to locate the JPEG library
(e.g. if the TIFF library is a static library).

If using --with-tiff and --without-jpeg works, either your TIFF
library doesn't have JPEG support, or it can find the JPEG library
without any assistance. Either way, adding --with-jpeg won't make any
difference.

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

Marco_Pasetti · March 28, 2008, 12:13am

If using --with-tiff and --without-jpeg works, either your TIFF library

doesn't have JPEG support, or it can find the JPEG library without any
assistance. Either way, adding --with-jpeg won't make any difference.

Yes, currently TIFF library doesn't have JPEG support (as this libjpeg is
not present in my MSYS environment);
I succesfully built libjpeg, but during tests it reported errors, so I
decided to remove it and then build TIFF without it; In wish list I meant to
add jpeg and its support in tiff.

Marco

-----Messaggio originale-----
Da: Glynn Clements [mailto:glynn@gclements.plus.com]
Inviato: venerdì 28 marzo 2008 1.03
A: Marco Pasetti
Cc: 'Moritz Lennert'; grass-dev@lists.osgeo.org
Oggetto: Re: R: [GRASS-dev] WinGRASS-6.3.0RC6 Self Installer

Marco Pasetti wrote:

>ODBC and maybe MySQL might be good things to add

They are actually in my wish list, along with jpeg support, FFMPEG,
xerces and some other things.

JPEG support doesn't actually mean anything.

None of the Makefiles use the JPEG variables (JPEGLIB, JPEGLIBPATH and
JPEGINCPATH).

The configure script uses the variables when testing for the TIFF library,
but that only matters if the TIFF library was built with JPEG support but it
requires specific switches to locate the JPEG library (e.g. if the TIFF
library is a static library).

If using --with-tiff and --without-jpeg works, either your TIFF library
doesn't have JPEG support, or it can find the JPEG library without any
assistance. Either way, adding --with-jpeg won't make any difference.

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

Marco_Pasetti · March 28, 2008, 10:35am

Hi Benjamin,

I think it is a good idea to encourage people to test-drive the
Python GUI. So go ahead as you suggested.

OK. Thanks

The main decision to make is:

Should we go for an all-inclusive WinGRASS that has every
format/capability which GDAL and GRASS provide?

Or should we keep it lean and stick to the most important
things, only adding small pieces at user-demand?

We also need to keep in mind that there should be some
serious testing of every driver added to the binary distribution.

That’s a very interesting issue. That’s my point of view:

All, I think, starts from a deep difference between Linux and Windows users: while *X user are used to easily download and compile packages reflecting their actual needs (even a beginner user can easiliy do that), it’s unthinkable to ask the same to Windows users (even if not beginners!); they need a precompiled, possibly selfcontained package (possibly only if other needed stuffs are already available as Win32 precompiled binaries). This said, I think that:

Even if we could provide precompiled binaries of the needed stuffs, without the need of reinventing the wheel every time (compiling sources by ourselves), I would highly prefer to provide WinGRASS packages including only stuffs directly compiled by ourselves. Currently WinGRASS package contains only 3 not compiled stuffs: MSYS, Bison and Flex. MSYS is the only application I would provide as precompiled binary, while I would prefer (in the future) to provide self-compiled versions of both Bison and Flex.
I think that, as you said, a serious testing of every driver added to the binary distribution is actually the main thing we should pay attenction to, before to consider to release any new driver support whitin GRASS and GDAL. This said, as it seems to be in contrast with what I recently did within WinGRASS packaging, I decided to add SQLite, PostgreSQL and Expat* support to GDAL and GRASS because they are needed for QGIS, and I don’t have enough time and machines to prepare different MSYS environment for both GRASS and QGIS projects.

Expat support is for GDAL only

because, as I said in the preamble, Windows users cannot download and compile by themselves extra-needed drivers and supports (in fact, they could, but it’s realistically unthinkable), I think that we should consider to add any possible extra stuff in WinGRASS packages, according with their consistency (they must definitely work) and with actual users needs (it’s a nonsence to add pieces not actually used or requested by users)

IMHO, that’s a possible point of view

Marco

Glynn_Clements1 · March 28, 2008, 11:31am

Marco Pasetti wrote:

I succesfully built libjpeg, but during tests it reported errors, so I
decided to remove it and then build TIFF without it; In wish list I meant to
add jpeg and its support in tiff.

Is there a reason to build these from source, rather than using the
GnuWin32 binaries:

http://gnuwin32.sourceforge.net/packages/jpeg.htm
http://gnuwin32.sourceforge.net/packages/tiff.htm

Ideally, we should build as little as possible ourselves.

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