[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]

Or, more succinctly:

If there is a flag to install the core packages (see what Vaclav and I did
in lines 296--304 at
https://github.com/awickert/gFlex/blob/master/r.flexure/r.flexure.py, for
example),
(1) Would you think that this is a good idea?
(2) To what directory should the external programs be downloaded and
installed? GRASS? The system?
(3) Oftentimes sudo privileges are needed for the install; should the
install go into a non-system-owned directory that is part of the path in
GRASS, or be available system-wide?

Thanks,

Andy

On Wed, Feb 4, 2015 at 2:02 AM, Andy Wickert <andrewwickert at gmail.com>
wrote:

> 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/ff585f83/attachment.html>