[GRASS-dev] Untangling geoPAT installation when updating GRASS version

Pierre Roudier pierre.roudier at gmail.com
Mon Feb 26 13:51:22 PST 2018


Dear Vaclav,

Here's what I ended up doing:

* I updated my GRASS trunk and compiled (./configure, make, then make
install)
* I applied your patch to geoPAT
* I ran make MODULE_TOPDIR=/usr/local/src/grass7_trunk/ in the geoPAT
directory

Unfortunately still the same issue running it in grass75:

GRASS 7.5.svn (modis_lst_2015):/usr/local/src/grass7_trunk > p.sig.grid
--help
ERROR: Module built against version $Revision: 70617 $ but trying to use
       version $Revision: 72230 $. You need to rebuild GRASS GIS or
       untangle multiple installations.

Any idea what I might have missed?

Cheers,

Pierre

On 26 February 2018 at 16:53, Vaclav Petras <wenzeslaus at gmail.com> wrote:

>
>
> On Sun, Feb 25, 2018 at 10:41 PM, Pierre Roudier <pierre.roudier at gmail.com
> > wrote:
>
>> Hi Vaclav, and thank you so much for your help,
>>
>
> You are welcome.
>
>
>>
>> Do I understand correctly that I should compile a version of GRASS to use
>> your patch?
>>
>
> The patch is for geoPAT, but I tested the subsequent compilation of geoPAT
> only against compiled GRASS (which is not `make install`ed).
>
>
>>
>> Cheers,
>>
>> P
>>
>> On 25 February 2018 at 15:52, Vaclav Petras <wenzeslaus at gmail.com> wrote:
>>
>>> Dear all,
>>>
>>> this may not address this specific problem with multiple installations,
>>> but it may help overall with debugging such problems because it is more
>>> direct. I'm attaching a geoPAT patch which deals with the names of the
>>> libraries and removes the need to modify GRASS source code before the
>>> compilation happens.
>>>
>>> The following command executed in the directory with the source code
>>> should be sufficient to compile modules with a self-compiled GRASS which is
>>> not in system:
>>>
>>> make MODULE_TOPDIR=~/.../trunk/ GRASS_VERSION_NUMBER=7.5.svn
>>>
>>> Path to the GRASS GIS installation/code/dev files and the version needs
>>> to be provided. This was tested with the current trunk in a home directory
>>> and not with GRASS installed (`make install`-ed) in the system.
>>> Nevertheless this removes the need to modify the source code and thus
>>> increasing compatibility with different GRASS versions (which change the
>>> copied and modified file).
>>>
>>> Besides the limited testing, there are three other issues:
>>>
>>> 1) g.extension is not able to install the code from a directory (or ZIP,
>>> ...) because no system for C addon modules with libraries is in place (same
>>> issue as with r.pi.* suite). When GRASS_VERSION_NUMBER is added to
>>> g.extension code and HTML for the main directory is resolved/or ignored in
>>> g.extension, modules at least compile, but nothing is installed (added) to
>>> the local addons directory.
>>>
>>> 2) I don't understand why GRASS_VERSION_NUMBER isn't already defined.
>>>
>>> 3) I don't know how to contribute to the geoPAT repository.
>>>
>>> Best,
>>> Vaclav
>>>
>>>
>>>
>>> On Fri, Feb 23, 2018 at 6:22 PM, Dylan Beaudette <
>>> dylan.beaudette at gmail.com> wrote:
>>>
>>>> How about your GRASS "development" files: installed via package
>>>> manager? Same version as the binaries?
>>>>
>>>> D
>>>>
>>>> On Fri, Feb 23, 2018 at 1:10 PM, Pierre Roudier
>>>> <pierre.roudier at gmail.com> wrote:
>>>> > Thanks Dylan,
>>>> >
>>>> > I did install using `sudo sh install.sh grass72` -- then `sudo sh
>>>> install.sh
>>>> > grass74` after my Grass version got updated to 7.4
>>>> >
>>>> > Cheers,
>>>> >
>>>> > P
>>>> >
>>>> > On 23 February 2018 at 18:41, Dylan Beaudette <
>>>> dylan.beaudette at gmail.com>
>>>> > wrote:
>>>> >>
>>>> >> Howdy Pierre!
>>>> >>
>>>> >> In my experience, the GeoPat modules need to know where several
>>>> things
>>>> >> are located, including (I think) parts of the GRASS source code. Have
>>>> >> a look through the install.sh code:
>>>> >>
>>>> >> http://sil.uc.edu/gitlist/geoPAT/blob/stable/install.sh
>>>> >>
>>>> >> I was able to get these modules up and running by invoking
>>>> install.sh like
>>>> >> this:
>>>> >>
>>>> >> sh install.sh grass75
>>>> >>
>>>> >> ... where "grass75" is the binary compiled from grass_trunk. The
>>>> >> install.sh code seemed to find the source code it needed and worked
>>>> >> without issue.
>>>> >>
>>>> >> How did you install / upgrade the Geopat modules? Could it be that
>>>> >> install.sh is "finding" the old source code / headers? Is there a
>>>> >> package for both GRASS binaries and development files?
>>>> >>
>>>> >> Dylan
>>>> >>
>>>> >>
>>>> >> On Thu, Feb 22, 2018 at 7:28 PM, Pierre Roudier
>>>> >> <pierre.roudier at gmail.com> wrote:
>>>> >> > Hi,
>>>> >> >
>>>> >> > I've been compiling the geoPAT extensions for GRASS from
>>>> >> > http://sil.uc.edu/gitlist/geoPAT/
>>>> >> >
>>>> >> > At the time I was running GRASS 7.2.2 installed from the Ubuntu GIS
>>>> >> > repository, but since this repo updated to GRASS 7.4, I have the
>>>> >> > following
>>>> >> > issue:
>>>> >> >
>>>> >> > GRASS 7.4.0 (modis_lst_2015):~ > p.sig.polygons --help
>>>> >> > ERROR: Module built against version $Revision: 70617 $ but trying
>>>> to use
>>>> >> >        version $Revision: 70829 $. You need to rebuild GRASS GIS or
>>>> >> >        untangle multiple installations.
>>>> >> > [Raster MASK present]
>>>> >> >
>>>> >> > Any pointers about how to resolve the version tangling? I've tried
>>>> >> > recompiling geoPAT, but that didn't work.
>>>> >> >
>>>> >> > Cheers,
>>>> >> >
>>>> >> > Pierre
>>>> >> >
>>>> >> > _______________________________________________
>>>> >> > grass-dev mailing list
>>>> >> > grass-dev at lists.osgeo.org
>>>> >> > https://lists.osgeo.org/mailman/listinfo/grass-dev
>>>> >
>>>> >
>>>> _______________________________________________
>>>> grass-dev mailing list
>>>> grass-dev at lists.osgeo.org
>>>> https://lists.osgeo.org/mailman/listinfo/grass-dev
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20180227/71e73c4f/attachment.html>


More information about the grass-dev mailing list