[GRASS-dev] how to formulate Makefiles for addons so that additional files get installed correctly by g.extension [was: Re: installing metadata addon fails]

Andy Wickert andrewwickert at gmail.com
Tue Feb 3 17:02:12 PST 2015


Hi all,

I don't see any replies to this, so I will add one. I have currently run
into a similar problem with r.flexure and v.flexure, two new extensions
that I added that reference a geophysical computer model I wrote (
https://github.com/awickert/gFlex). I would also in the future really like
to write GRASS GIS interfaces to a large number of additional
glacier/climate/geological models, as the GRASS Python interface makes this
really easy, and it is nice to have the data displayed in the same
coordinate system and database that holds the field data. So I have a
vested interest in finding a general solution!

Are there any ideas on how to do this? What I just did (and mentioned to
Vaclav) was this:

try:
  import gflex # (my model)
except:
  print ""
  print "MODULE IMPORT ERROR."
  print "In order to run r.flexure or g.flexure, you must download and
install"
  print "gFlex. The most recent development version is available from"
  print "https://github.com/awickert/gFlex."
  print "Installation instructions are available on the page."
  grass.fatal("Software dependency must be installed.")

I also thought of some sort of prompt to the user to download the model,
and Vaclav had some ideas as well. He's going to show me how to arrange my
imports so the help files compile properly without gflex available, so my
email to the list is instead to discuss a framework for future integration
of GRASS GIS with outside (but also open-source) software (and of course
solving these immediate issues as well).

Best,

Andy

On Tue, Jan 13, 2015 at 10:31 AM, Moritz Lennert <
mlennert at club.worldonline.be> wrote:

> On 13/01/15 01:20, Glynn Clements wrote:
>
>>
>> Moritz Lennert wrote:
>>
>>  So I guess #2480 and #2534 have to be treated individually on a
>>> case-by-case basis ?
>>>
>>
>> What exactly is the issue there?
>>
>> If building them manually works, that suggests a problem with
>> g.extension.
>>
>>
> In both cases, I can run
>
> make MODULE_TOPDIR=../../../../grass70_release/dist.x86_64-
> unknown-linux-gnu/
>
> from the respective directories in the grass-addons svn tree without any
> problems.
>
> AFAIU, #2097 also has similar issues: here g.extension installs everything
> fine, but then the installed script cannot find the additional (library)
> files.
>
> So, maybe I should reformulate my original question:
>
> When a python addon uses additional .py files,
>
> 1) Do we have general rules as to what should be installed where (r.modis
> installs additional files in a r.modis directory in the local addons
> directory : .grass7/addons/r.modis - should addons create such directories
> there or should they go into .grass7/addons/etc ?
>
> 2) How should the Makefile be formulated so that all the additional files
> get installed by g.extension ? This currently does not seem to work for at
> least i.segment.hierarchical and v.class.ml.
>
> Moritz
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20150204/ffeb46b1/attachment.html>


More information about the grass-dev mailing list