[GRASS-dev] WinGRASS Plans

GRASS GRASS developer
,
1

Hi all,

I would like to talk with you about new ideas/changes related to the WinGRASS Project:

ITEM 1

I bought a new notebook with Vista installed, and I’m building a new MSYS environment (+ GRASS, obviously) on it; I hope that future testings will confirm that the binaries built here will be fine for both XP and Vista.

Since now (I’m still building) I introduced the following changes:

  • added the libjpeg support (specially needed for QGIS, actually)
  • upgraded libpng from the 1.2.24 to the 1.2.29 release
  • upgraded GSL from the 1.9 to the 1.11 release (actually, only another QGIS requirement)
  • upgraded PostgreSQL from the 8.2.6 to the 8.3.1 release
  • upgraded SQLite from the 3.5.6 to 3.5.9 release

then I planned to add:

any suggestions? what should I add more?

In the WinGRASS Current Status Wiki (ToDo → Dependencies) I read: compile with wx for wx gui v.digit replacement
IIRC, to enable wxWidgets in the MSYS build we need a compiled (not prebuilt) version of Python, but, at the moment, it’s not possible to compile Python under MSYS/MinGW. Is it (or will it be) strictly necessary to build the new v.digit module?

ITEM 2

Since now, the WinGRASS installer comes with a README html file built in. That file is the same published on the GRASS website; that means that we actually have a redundant replication in our SVN: the same file in /root/grass-web/trunk/grass63/mswindows/native and in /root/grass/branches/develbranch_6/mswindows/Extras

I would like to remove the REAME.html file from the installer (and thus from the grass/…/Extras folder) and replace it with an http link to the README.html into the GRASS web site. Thus we will remove the redundant replication and I will avoid the problem to always check the differences from those two files.

ITEM 3

I would like to add some images and icons to the WinGRASS web page, as done here http://www.webalice.it/marco.pasetti/grass/BuildFromSource.html, and change the page structure such as the web-page of GRASS on MacOSX (http://grass.osgeo.org/grass63/binary/macosx/), moving the download section from the top of the page to the main html document itself (that also means that I’ll probably need to rename it from README.html to index.html, but it depends on the current apache settings)

Then it would be good to also add a Binary Revision History section where to explain the changes occurred between the different GRASS binary releases

ITEM 4

Since I’m very short of spare time, but the GRASS BuildFromSource document is a relevant documentation for the GRASS community, I think that I could move the Building Guide directly into the grass-web mswindows folder, waiting for better times when I’ll definetely put it into the official wiki.

ITEM 4

Since Windows users cannot build binaries by themselves, it would be good to build and distribute also the GRASS AddOns. I’m not sure now how to distribute them (even if I’ve got some WIP ideas), but I surely need to create a simple procedure to build and install them all in a separated directory, with a build procedure indipendent from the GRASS build procedure itself.

Since now I built addons putting the sources in the GRASS source tree and adding the addons to build in the general make files (for example adding r.horizon into the list of building modules in /raster/Makefile). But if I put the addons sources outside the main GRASS source tree, I would need to change the paths from relative to absolute in each module, and then create a Makefile for each addon module… too much work for a frequent task! Any suggestions?

Thanks for all your patience,

Marco

2

On Thu, Jun 5, 2008 at 3:20 PM, <marco.pasetti@alice.it> wrote:
[ great stuff skipped]
...

Since Windows users cannot build binaries by themselves, it would be good to
build and distribute also the GRASS AddOns. I'm not sure now how to
distribute them (even if I've got some WIP ideas), but I surely need to
create a simple procedure to build and install them all in a separated
directory, with a build procedure indipendent from the GRASS build procedure
itself.

I feel that the *build* procedure is pretty dependent on the GRASS build
procedure. But that's no problem:

Since now I built addons putting the sources in the GRASS source tree and
adding the addons to build in the general make files (for example adding
r.horizon into the list of building modules in /raster/Makefile). But if I
put the addons sources outside the main GRASS source tree, I would need to
change the paths from relative to absolute in each module, and then create a
Makefile for each addon module... too much work for a frequent task! Any
suggestions?

That's not needed. You can compile with:

cd grass-addons/raster/r.sun_horizon/
make MODULE_TOPDIR=$HOME/grass64/

This will compile it into the main GRASS code tree.

Markus

3

marco.pasetti@alice.it wrote:

In the WinGRASS Current Status Wiki (ToDo -> Dependencies) I read:
compile with wx for wx gui v.digit replacement
IIRC, to enable wxWidgets in the MSYS build we need a compiled (not
prebuilt) version of Python, but, at the moment, it's not possible to
compile Python under MSYS/MinGW.

The GUI *should* work with the official Windows (and MacOSX) releases
of Python and wxPython. If it doesn't, that needs to be fixed;
requiring a "custom" version of either isn't acceptable. That includes
the vdigit module.

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

4

Markus,

That's not needed. You can compile with:

cd grass-addons/raster/r.sun_horizon/
make MODULE_TOPDIR=$HOME/grass64/

This will compile it into the main GRASS code tree.

very good! Thanks

the last thing I have to check (when I'll finish to build all) is where the binaries will be created. I'll see when I'll try to build one.
Then I'll need to create a script to automatically build all the addons in the repository. I will work on it.

Thanks,

Marco