[GRASS-dev] wingrass-addons: manifests

GRASS GIS GRASS GIS developer
1

Hi,

when building addons for winGRASS I am having problem with creating
manifests, see [1].

make OBJ.i686-pc-mingw32/i.points.auto.manifest.res && gcc
-L/osgeo4w/usr/src/grass_trunk/dist.i686-pc-mingw32/lib
-L/osgeo4w/usr/src/grass_trunk/dist.i686-pc-mingw32/lib
-Wl,--export-dynamic,--enable-runtime-pseudo-reloc -L/c/OSGeo4W/lib
-L/osgeo4w/usr/src/grass_trunk/mswindows/osgeo4w/lib -o
/c/Users/landa/grass_packager/grass70/addons/i.points.auto/bin/i.points.auto.exe
OBJ.i686-pc-mingw32/cellhd.o OBJ.i686-pc-mingw32/creat_rand.o
OBJ.i686-pc-mingw32/crs.o OBJ.i686-pc-mingw32/equ.o
OBJ.i686-pc-mingw32/find_points.o OBJ.i686-pc-mingw32/group.o
OBJ.i686-pc-mingw32/main.o OBJ.i686-pc-mingw32/overlap.o
OBJ.i686-pc-mingw32/target.o
/osgeo4w/usr/src/grass_trunk/dist.i686-pc-mingw32/lib/fmode.o
OBJ.i686-pc-mingw32/i.points.auto.manifest.res -lgrass_imagery.7.0.svn
-lgrass_gmath.7.0.svn -lgrass_raster.7.0.svn -lgrass_gis.7.0.svn
-lintl -lfftw3 -lxdr -liberty -lws2_32
make[1]: Entering directory
`/c/osgeo4w/usr/src/grass_addons/grass7/imagery/i.points.auto'
make[1]: *** No rule to make target
`OBJ.i686-pc-mingw32/i.points.auto.manifest.res'. Stop.
make[1]: Leaving directory
`/c/osgeo4w/usr/src/grass_addons/grass7/imagery/i.points.auto'
make: *** [/c/Users/landa/grass_packager/grass70/addons/i.points.auto/bin/i.points.auto.exe]
Error 2

Any idea what is missing in the compilation script?

Thanks in advance, Martin

[1] http://trac.osgeo.org/grass/browser/grass-addons/tools/addons/compile.sh#L46

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

2

Hi,

Martin wrote:

when building addons for winGRASS I am having problem with
creating manifests, see [1].

make OBJ.i686-pc-mingw32/i.points.auto.manifest.res

...

Any idea what is missing in the compilation script?

do you get the same with another module? It builds for me ok
on linux, but maybe there is some unknown in the newish code..?
I recently fixed the Makefile for that in grass6 addons*, but
until this post I had not noticed MMz had ported it to grass7,
or considered anyone would even attempt that due to the past
i.points interactive Xmon dependency.. (nice!)
[*] some other minor stuff too which might be sync'd, if needed.

other notes:
* http://grass.osgeo.org/addons/grass6.xml
   ?? <addons version="7.0.svn"> in the grass6.xml file?
   ?? d.barb: why no <description> loaded?

* wxGUI extension removal:
I don't think it is very wise to rely on a volatile generated file on
a remote server to decide which files to delete on my local machine.
Frankly it seems a bit dangerous to me to have a remote script making
those decisions on my behalf. The filenames of what to remove are
entirely predictable (even html/module_*.png), and may well change
between the time of install and the time of removal, so I would
suggest to abandon the <binary><file>s. Was there some win32 reason
to do that, or..?

* wingrass uninstall now also removes the addon dir? I guess it is in case
a replacement install has a different GIS_H version, but what if the user
legitimately put some of their self-authored scripts in there? If that
must stay for some reason, there should at least be a "Are you really sure
you want to do this?" dialog, as non-accidentally deleting users' personal
scripts will not be good for business.

thanks,
Hamish

3

2011/12/5 Hamish <hamish_b@yahoo.com>:

when building addons for winGRASS I am having problem with
creating manifests, see [1].

make OBJ.i686-pc-mingw32/i.points.auto.manifest.res

...

Any idea what is missing in the compilation script?

do you get the same with another module? It builds for me ok
on linux, but maybe there is some unknown in the newish code..?

manifest are built only on Windows...

[...]

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

4

2011/12/5 Hamish <hamish_b@yahoo.com>:

[...]

* http://grass.osgeo.org/addons/grass6.xml
?? <addons version="7.0.svn"> in the grass6.xml file?

fixed in r49549

?? d.barb: why no <description> loaded?

Compilation just fails (on Windows only), problem with creating BAT
files (probably similar issue as with manifests).

* wxGUI extension removal:
I don't think it is very wise to rely on a volatile generated file on
a remote server to decide which files to delete on my local machine.
Frankly it seems a bit dangerous to me to have a remote script making
those decisions on my behalf. The filenames of what to remove are
entirely predictable (even html/module_*.png), and may well change
between the time of install and the time of removal, so I would
suggest to abandon the <binary><file>s. Was there some win32 reason
to do that, or..?

The main reason is that some of the modules install some extra
components which can be hardly guessed by `g.extension` module (see
`grass7/r.modis` and others). Well, relay on generated files on the
remote server when deleting the files is not a "wise" idea. Probably
`g.extension` should install also some metadata file locally about
which files to remove when uninstalling. Then `g.extension
ext=<module> ope=remove` would just report which files is going to be
removed and `g.extension ext=<module> ope=remove -f` would remove
them. Seems to be better solution for you?

* wingrass uninstall now also removes the addon dir? I guess it is in case
a replacement install has a different GIS_H version, but what if the user
legitimately put some of their self-authored scripts in there? If that
must stay for some reason, there should at least be a "Are you really sure
you want to do this?" dialog, as non-accidentally deleting users' personal
scripts will not be good for business.

Well, it has been removing the whole GRASS6 directory in the past (so
also `addons`) subdirectory. From this point of view nothing has been
changed. I think that the whole $APPDATA\GRASSX should be untouched
when uninstalling winGRASS. I will changed the installer according
that.

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

5

Martin Landa wrote:

when building addons for winGRASS I am having problem with creating
manifests, see [1].

make[1]: Entering directory
`/c/osgeo4w/usr/src/grass_addons/grass7/imagery/i.points.auto'
make[1]: *** No rule to make target
`OBJ.i686-pc-mingw32/i.points.auto.manifest.res'. Stop.

make[1]: Leaving directory
`/c/osgeo4w/usr/src/grass_addons/grass7/imagery/i.points.auto'
make: *** [/c/Users/landa/grass_packager/grass70/addons/i.points.auto/bin/i.points.auto.exe]
Error 2

Any idea what is missing in the compilation script?

Do the following files exist:

  $(MODULE_TOPDIR)/mswindows/generic.manifest.rc
  $(MODULE_TOPDIR)/mswindows/generic.manifest
?

Those are the ultimate pre-requisites for %.manifest.res.

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

6

Hamish:

> * wxGUI extension removal:
> I don't think it is very wise to rely on a volatile
> generated file on a remote server to decide which files to
> delete on my local machine.

...

> Was there some win32 reason to do that, or..?

Martin:

The main reason is that some of the modules install some
extra components which can be hardly guessed by `g.extension`
module (see `grass7/r.modis` and others).

..

Well, relay on generated files on the remote server when
deleting the files is not a "wise" idea.

... and this aspect would bite us often:

and may well change between the time of install and the
time of removal,

Probably `g.extension` should install also some metadata
file locally about which files to remove when uninstalling.

to be honest I'm not really worried if option=remove left over
a few orphaned files in corner cases, as remove= doesn't get
run very much anyway. shrug.

how about $addons/docs/manifests/g.module.files or g.module.list?

another question to consider is if it is desired to remove addons
which have been installed system wide? (if run with suitable
admin rights) I'm not completely sure that it is, probably it
just feels weird as we've never had a 'make uninstall' before.

Then `g.extension ext=<module> ope=remove` would just report
which files is going to be removed and `g.extension
ext=<module> ope=remove -f` would remove them. Seems to be
better solution for you?

Sounds alright, but is it overkill? (again, it's not something
I would have bothered with, but I don't really mind)

Hamish:

> * wingrass uninstall now also removes the addon dir?

...

> there should at least be a "Are you really sure
> you want to do this?" dialog, as non-accidentally
> deleting users' personal scripts will not be good for
> business.

Martin:

I think that the whole $APPDATA\GRASSX should be untouched
when uninstalling winGRASS. I will changed the installer
according that.

perhaps like some other Windows uninstallers it could have a
tick box in the dialog wizard: "Also remove configuration and
addon modules?"

or, perhaps break that down into two tick boxes? one for config
files and the other for addons? (As seen by Johannes's post
yesterday to grass-dev there is demand for an in-path home for
personal addon scripts.)

the main thing to ensure is that left-over temporary files get
removed. the config files are tiny, but the accumulation of temp
files can be huge. I think we've fixed the wingrass file delete
bug now so it won't be as bad as it used to be, but it is worth
checking in case of blue screens and unclean exits.

(OT: also abandoned /tmp/grass7-$USER-$PID/ dirs seem quite
common; we're missing a cleanup() catch somewhere)

many shrugs,
Hamish

7

Hi,

2011/12/5 Martin Landa <landa.martin@gmail.com>:

ext=<module> ope=remove` would just report which files is going to be
removed and `g.extension ext=<module> ope=remove -f` would remove
them. Seems to be better solution for you?

applied in trunk for testing (r49578).

$ g.extension ext=i.points.auto ope=remove
Files to be removed (use flag 'f' to force removal):
/home/martin/.grass7/addons/bin/i.points.auto
/home/martin/.grass7/addons/man/man1/i.points.auto.1
/home/martin/.grass7/addons/docs/html/i.points.auto.html
WARNING: Extension <i.points.auto> not removed. Re-run 'g.extension' with
         'f' flag to force removal

$ g.extension ext=i.points.auto ope=remove -f
Extension <i.points.auto> successfully uninstalled.

Reasonable approach for you (GRASS users)?

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

8

Hi,

2011/12/5 Glynn Clements <glynn@gclements.plus.com>:

Do the following files exist:

   $\(MODULE\_TOPDIR\)/mswindows/generic\.manifest\.rc
   $\(MODULE\_TOPDIR\)/mswindows/generic\.manifest

?

there are missing. Probably makefile should be updated to install them
to $ARCH_DISTDIR/mswindow, right?

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

9

2011/12/7 Martin Landa <landa.martin@gmail.com>:

Hi,

2011/12/5 Glynn Clements <glynn@gclements.plus.com>:

Do the following files exist:

   $\(MODULE\_TOPDIR\)/mswindows/generic\.manifest\.rc
   $\(MODULE\_TOPDIR\)/mswindows/generic\.manifest

?

there are missing. Probably makefile should be updated to install them
to $ARCH_DISTDIR/mswindow, right?

hm, not really needed. Building winGRASS addons solved in r49580.

Thanks for the support, Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

10

Martin Landa wrote:

> Do the following files exist:
>
> $(MODULE_TOPDIR)/mswindows/generic.manifest.rc
> $(MODULE_TOPDIR)/mswindows/generic.manifest
> ?

there are missing. Probably makefile should be updated to install them
to $ARCH_DISTDIR/mswindow, right?

They should be installed somewhere, although I'm not quite sure where.
A similar issue exists for Doxyfile_arch_{html,latex}.

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