g.extension does not work on a Mac

[cmbarton]

g.extension does not work on a Mac. It seems to assume that GRASS is being run from a source directory and tries to drop the files into the grass.app rather than the source. So it gets a no make target error.

It needs to ask where the source directory is located, put the source files there, and run make, followed by make install.

The manual should also clearly indicate that a successfully compiled GRASS source distribution is required in order for this to work.

The error is below using v.strahler as an example:

g.extension extension=v.strahler svnurl=https://svn.osgeo.org/grass/grass-addons/ prefix=/Library/Application\ Support/GRASS/7.0 menuitem=Vector;Stream order
'/Library/Application\ Support/GRASS/7.0' created
Fetching 'v.strahler' from GRASS-Addons SVN (be patient)...
A    v.strahler/v.mainchannel
A    v.strahler/v.mainchannel.html
A    v.strahler/forest2tree.c
A    v.strahler/description.html
A    v.strahler/r.strahler.sh
A    v.strahler/helper.c
A    v.strahler/r.strahler.sh.html
A    v.strahler/images
A    v.strahler/images/at_rbroscoe.jpg
A    v.strahler/images/Qgisout_vstrahler.jpg
A    v.strahler/images/thrVScell.jpg
A    v.strahler/images/wt_rbroscoe.jpg
A    v.strahler/images/input_vstrahler.jpg
A    v.strahler/images/menotre.jpg
A    v.strahler/images/output_vstrahler.jpg
A    v.strahler/images/lr_rbroscoe.jpg
A    v.strahler/main.c
A    v.strahler/r.broscoe.sh
A    v.strahler/strahler.c
A    v.strahler/r.broscoe.sh.html
A    v.strahler/documentation
A    v.strahler/documentation/r.broscoe_flowchart.dia
A    v.strahler/documentation/v.strahler_flowchart.jpeg
A    v.strahler/documentation/r.broscoe_flowchart.jpeg
A    v.strahler/documentation/v.strahler_flowchart.dia
A    v.strahler/strahler.h
A    v.strahler/write.c
A    v.strahler/Makefile
Checked out revision 40210.
Compiling 'v.strahler'...
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/include/Mak
e/Rules.make:16: warning: overriding commands for target
`/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-
darwin10.2.0'
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/include/Mak
e/Rules.make:16: warning: ignoring old commands for target
`/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-
darwin10.2.0'
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/include/Mak
e/Rules.make:16: warning: overriding commands for target
`/Users/cmbarton/grass_dev/grass70_dev/bin.i386-apple-
darwin10.2.0'
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/include/Mak
e/Rules.make:16: warning: ignoring old commands for target
`/Users/cmbarton/grass_dev/grass70_dev/bin.i386-apple-
darwin10.2.0'
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/include/Mak
e/Rules.make:16: warning: overriding commands for target
`/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-
darwin10.2.0/include/grass'
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/include/Mak
e/Rules.make:16: warning: ignoring old commands for target
`/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-
darwin10.2.0/include/grass'
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/include/Mak
e/Rules.make:16: warning: overriding commands for target
`/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-
darwin10.2.0/lib'
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/include/Mak
e/Rules.make:16: warning: ignoring old commands for target
`/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-
darwin10.2.0/lib'
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/include/Mak
e/Rules.make:16: warning: overriding commands for target
`/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-
darwin10.2.0/bin'
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/include/Mak
e/Rules.make:16: warning: ignoring old commands for target
`/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-
darwin10.2.0/bin'
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/include/Mak
e/Rules.make:16: warning: overriding commands for target
`/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-
darwin10.2.0/etc'
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/include/Mak
e/Rules.make:16: warning: ignoring old commands for target
`/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-
darwin10.2.0/etc'
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/include/Mak
e/Rules.make:16: warning: overriding commands for target
`/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-
darwin10.2.0/driver'
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/include/Mak
e/Rules.make:16: warning: ignoring old commands for target
`/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-
darwin10.2.0/driver'
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/include/Mak
e/Rules.make:16: warning: overriding commands for target
`/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-
darwin10.2.0/driver/db'
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/include/Mak
e/Rules.make:16: warning: ignoring old commands for target
`/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-
darwin10.2.0/driver/db'
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/include/Mak
e/Rules.make:16: warning: overriding commands for target
`/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-
darwin10.2.0/fonts'
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/include/Mak
e/Rules.make:16: warning: ignoring old commands for target
`/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-
darwin10.2.0/fonts'
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/include/Mak
e/Rules.make:16: warning: overriding commands for target
`/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-
darwin10.2.0/docs'
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/include/Mak
e/Rules.make:16: warning: ignoring old commands for target
`/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-
darwin10.2.0/docs'
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/include/Mak
e/Rules.make:16: warning: overriding commands for target
`/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-
darwin10.2.0/docs/html'
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/include/Mak
e/Rules.make:16: warning: ignoring old commands for target
`/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-
darwin10.2.0/docs/html'
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/include/Mak
e/Rules.make:16: warning: overriding commands for target
`/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-
darwin10.2.0/man'
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/include/Mak
e/Rules.make:16: warning: ignoring old commands for target
`/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-
darwin10.2.0/man'
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/include/Mak
e/Rules.make:16: warning: overriding commands for target
`/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-
darwin10.2.0/man/man1'
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/include/Mak
e/Rules.make:16: warning: ignoring old commands for target
`/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-
darwin10.2.0/man/man1'
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/include/Mak
e/Rules.make:16: warning: overriding commands for target
`/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-
darwin10.2.0/tools'
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/include/Mak
e/Rules.make:16: warning: ignoring old commands for target
`/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-
darwin10.2.0/tools'
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/include/Mak
e/Rules.make:19: warning: overriding commands for target
`OBJ.i386-apple-darwin10.2.0'
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/include/Mak
e/Rules.make:19: warning: ignoring old commands for target
`OBJ.i386-apple-darwin10.2.0'
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/include/Mak
e/Rules.make:41: warning: overriding commands for target
`clean'
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/include/Mak
e/Rules.make:41: warning: ignoring old commands for target
`clean'
make: *** No rule to make target
`/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-
darwin10.2.0/docs/html/.html', needed by `html'.  Stop.
ERROR: Compilation failed, sorry. Please check above error messages.
(Sun Jan  3 14:46:24 2010) Command finished (20 sec)                            

[kyngchaos]

Replying to cmbarton:

It needs to ask where the source directory is located, put the source files there, and run make, followed by make install.

The manual should also clearly indicate that a successfully compiled GRASS source distribution is required in order for this to work.

I believe the intent is to NOT require a built source dir, or source at all. It's likely that work is needed so that the installed platform.make has the install paths instead of the original build paths, OR that it overrides GRASS_HOME and RUN_GISBASE when running make (better, since the install path could change).

g.extension extension=v.strahler svnurl=​https://svn.osgeo.org/grass/grass-addons/ prefix=/Library/Application\ Support/GRASS/7.0 menuitem=Vector;Stream order

Note: the correct OSX addons dir is /Library/Application Support/GRASS/7.0/Modules.

[hamish]

Replying to kyngchaos:

Replying to cmbarton:

g.extension extension=v.strahler svnurl=​https://svn.osgeo.org/grass/grass-addons/ prefix=/Library/Application\ Support/GRASS/7.0 menuitem=Vector;Stream order

Note: the correct OSX addons dir is /Library/Application Support/GRASS/7.0/Modules.

Hi,

In 6.5svn I've just checked in an update which quotes all variables and it should work better when there are spaces in pathnames now.

specifically, ${} is not enough to protect against spaces when used as a command line argument.

this makes two directories, a/ and path/

foo="a path"
mkdir ${foo}

ls
rmdir $foo

(I'll merge it to the other branches this evening once I get the chance)

Hamish

[cmbarton]

Replying to kyngchaos:

Replying to cmbarton:

It needs to ask where the source directory is located, put the source files there, and run make, followed by make install.

The manual should also clearly indicate that a successfully compiled GRASS source distribution is required in order for this to work.

I believe the intent is to NOT require a built source dir, or source at all. It's likely that work is needed so that the installed platform.make has the install paths instead of the original build paths, OR that it overrides GRASS_HOME and RUN_GISBASE when running make (better, since the install path could change).

How can this work without the GRASS libraries, platform.make, etc?

g.extension extension=v.strahler svnurl=​https://svn.osgeo.org/grass/grass-addons/ prefix=/Library/Application\ Support/GRASS/7.0 menuitem=Vector;Stream order

Note: the correct OSX addons dir is /Library/Application Support/GRASS/7.0/Modules.

Hmm. I thought I put this in the field. I'll have to check again.

Michael

[hamish]

see also #620, #1178, and #1180

[kyngchaos]

I got a chance to poke around.

Problems I identified:

• as mentioned on the mailing list, $GRASS_ADDON_PATH can't be used because g.extension needs a single path, while GRASS_ADDON_PATH can have multiple paths, and does in my Mac distribution (a global and user addon path). The workaround is to specify the user path when running g.extension. That's:
  • /Library/GRASS/6.4/Modules for the global path for GRASS 6.4 (and 6.5, just change the version in the path)
  • ~/Library/GRASS/6.4/Modules for the user path (and similar for 6.5) */Library/Application Support/GRASS/7.0/Modules for the global path for GRASS 7.0 (and similar for future versions) *~/Library/Application Support/GRASS/7.0/Modules for the user path for GRASS 7.0 (and similar for future versions)
• the makefile parts are hardwired to the source. This can be overridden when running make, it's just a matter of figuring out which to do.
• the compile stage compiles to ARCH_DISTDIR, which is constructed from GISBASE, which is the installed app. Even if the user uses a prefix that they have permissions to, they will still need admin privileges to compile
• mkhtml.sh and g.html2man are not installed, so installation only partially succeeds - binaries are installed but not help files, and g.extension reports it as a failed install.

I was able to get partial compilation and installation (without the help files) by overriding a few more make variables (patch attached):

• ARCH_DISTDIR = TMPDIR/dist
• ARCH_LIBDIR = GISBASE/lib
• ARCH_INC = GISBASE/include, MYINST_DIR/include and TMPDIR/dist/include
• ARCH_LIBPATH = GISBASE/lib, MYINST_DIR/lib and TMPDIR/dist/lib

This will also find addon includes and libs that might be needed from another addon (ie for a group of addons).

Fixing help compilation needs some more changes:

• install tools/mkhtml.sh and tools/g.html2man
• mkhtml.sh is found from MODULE_TOPDIR (in html.make), so that should work, but g.html2man is found from GRASS_HOME (in man.make). Either change man.make to use MODULE_TOPDIR for consistency, or add another make override for GRASS_HOME.

[neteler]

Great, this patch solved also a problem on Linux, turning g.extension to functional under conditions where the current 6.4.svn version fails. Please submit.

[kyngchaos]

r46220 (rel64) and r46221 (dev6) for my patch as far as it goes. I haven't looked at GRASS 7 yet.

I'll work on the help file compilation next. Can you think of any reason not to install mkhtml.sh and g.html2man? ie dangerous actions in the scripts, ...

[kyngchaos]

OK, the help files issue is partly my fault for OS X - the OS X install was missing the tools dir, and the main GRASS makefile does install mkhtml.sh. Fixed for OS X.

g.html2man still needs to be installed. It looks like mkhtml.sh was hacked to install into the dist dir during compilation from the main makefile, instead of from the tools/ makefile, so I'd say just do the same for g.html2man.

Otherwise, I tested with those installed, plus the man.make change, and g.extension worked without a failure.

[kyngchaos]

In adding the install for g.html2man (r46240 in rel64, r46241 in dev6), I found an update (r45933) by martinl that did that, though it was broken (didn't make sure g.html2man subfolder existed). But also he had an old copy of the Makefile and I had to fix a reversion.

And instead of my changes to g.extension to change ARCH_* vars, martin hacked platform.make, grass.make and man.make on install to change the make vars.

Though it probably needs a few more vars updated to match what I did, which is the better method? Seems to me to change 1 file, g.extension, is better than to change 3. But maybe there are other uses for the makefiles outside g.extension?

I guess both methods won't hurt...

[kyngchaos]

Copied the wrong var name in man.make. fixed in r46245/r46246.

[neteler]

Looks much better than ever now. A remaining flaw is there:

• Linux binary snapshot taken from web site (I forced created some minutes ago)

​http://grass.osgeo.org/grass64/binary/linux/snapshot/

• installed into user's home into the $HOME/grass64/ directory

• g.extension failed upon wrong parameters in Platform.make

I updated manually Platform.make (differences attached): all fine, g.extension works. The missing issue is to update the script "binaryInstall.src" which generates

grass-6.4.2svn-x86_64-unknown-linux-gnu-12_05_2011-install.sh

in order to have a correct include/Make/Platform.make after installed.

[neteler]

Fixes for Platform.make *after* installation

[martinl]

Replying to kyngchaos:

In adding the install for g.html2man (r46240 in rel64, r46241 in dev6), I found an update (r45933) by martinl that did that, though it was broken (didn't make sure g.html2man subfolder existed). But also he had an old copy of the Makefile and I had to fix a reversion.

I don't understand fully "he had an old copy", I modified fresh Makefile from SVN.

And instead of my changes to g.extension to change ARCH_* vars, martin hacked platform.make, grass.make and man.make on install to change the make vars.

Well, I though I have fixed wrongly set variables, probably I was wrong.

Though it probably needs a few more vars updated to match what I did, which is the better method? Seems to me to change 1 file, g.extension, is better than to change 3. But maybe there are other uses for the makefiles outside g.extension?

I think that makefiles should provide up-to-date variables.

BTW, your commit introduced again 'macosx' directory. What is the reason for this directory on GNU/Linux or MS Windows? Thanks. Martin

[kyngchaos]

Replying to martinl:

BTW, your commit introduced again 'macosx' directory. What is the reason for this directory on GNU/Linux or MS Windows? Thanks. Martin

That's what made me think you had an old copy. The test on whether to build the MACOSX_APP stuff is in the macosx/Makefile, so nothing will happen on other systems. Either way is fine.

I'm not trying to blame anyone, but I think I had originally done it your way in the top level makefile, but glynn changed it. Or he changed something similar elsewhere, and I changed this case to match.

[martinl]

Replying to kyngchaos:

Replying to martinl:

BTW, your commit introduced again 'macosx' directory. What is the reason for this directory on GNU/Linux or MS Windows? Thanks. Martin

That's what made me think you had an old copy. The test on whether to build the MACOSX_APP stuff is in the macosx/Makefile, so nothing will happen on other systems. Either way is fine.

OK, thanks for clarification.

[glynn]

Replying to kyngchaos:

I think I had originally done it your way in the top level makefile, but glynn changed it. Or he changed something similar elsewhere, and I changed this case to match.

Note that I hardly ever touch 6.x. Most of the problems stem from trying to back-port isolated parts of 7.x to 6.x, when the changes to the build system are highly inter-dependent. But back-porting the entire build system would run into problems with "unusual" modules (most of which have been eliminated from 7.x).

BTW: one of the original reasons for not keeping the 6.x build system in sync was that the 7.x build system absolutely requires GNU make 3.81, which wasn't universally available at the time (e.g. MacOSX was still on 3.79). I don't think that's an issue any more.

[kyngchaos]

In talking with Michael off-list, I came up with the following summary of issues with the current state of g.extension:

Clearly define what GRASS_ADDON_PATH is. It should be one thing only. Currently in GRASS 7 it can be a mix of bin (full) paths and prefix paths, and is just messy and confusing. I'd recommend (I'm sure I mentioned something like this before) that to keep backwards compatibility, GRASS_ADDON_PATH should be left as it's always been defined: full paths to executable folders (ie .../bin). Add a new variable for "extensions" that includes prefix paths where bin and scripts (possibly etc and lib) subfolders are found. Use this new variable for g.extension, as well as adding the /bin and /scripts subfolders to the PATH in grass.py.

grass.py needs to handle multiple paths in GRASS_ADDON_PATH. Really, with the above recommendation, GRASS_ADDON_PATH can be simply added to PATH as it always has been, and the new var would get the /bin & /scripts treatment.

Currently, it adds GRASS_ADDON_PATH to the PATH (the old definition of full paths to ../bin) and adds subfolders to GRASS_ADDON_PATH as a whole to /bin and /scripts to the PATH. ie, the OSX startup sets GRASS_ADDON_PATH as:

$HOME/Library/Application Support/GRASS/7.0/Modules/bin:/Library/Application Support/GRASS/7.0/Modules/bin

What gets added to the PATH is:

/Users/kyngchaos/Library/Application Support/GRASS/7.0/Modules/bin:
/Library/Application Support/GRASS/7.0/Modules/bin/bin:
/Users/kyngchaos/Library/Application Support/GRASS/7.0/Modules/bin:
/Library/Application Support/GRASS/7.0/Modules/bin/scripts

change the OSX startup use the new var. The OSX default paths were designed as prefix paths, though only the bin subfolders were added to GRASS_ADDON_PATH.

change g.extension to use the new var. then it should start working properly.

[neteler]

Duplicate of g.extension bug #1406 ?

[neteler]

Is this problem solved as is bug #1406 ?

[cmbarton]

I don't know where this is at currently. Has a new 'extension' variable been defined? I followed the discussion and see a good suggestion to resolving this, but don't know if anyone has actually done it.

Michael

[neteler]

Here a test on Ubuntu with GRASS 7, via the wxGUI extension manager:

(Fri Sep  7 04:01:24 2012)                                                      
g.extension extension=r.houghtransform svnurl=http://svn.osgeo.org/grass/grass-addons/grass7
Fetching <r.houghtransform> from GRASS-Addons SVN (be patient)...
Compiling...
...
linesegmentsextractor.cpp:133:37: warning: conversion to
‘int’ from ‘size_t {aka long unsigned int}’ may
alter its value [-Wconversion]
linesegmentsextractor.cpp:136:21: warning: conversion to
‘float’ from ‘double’ may alter its value
[-Wconversion]
/bin/sh: 1: /media/Proyectos/GISData_grass/South_america_cli
mate_lonlat/Ortiz_j/.tmp/cito/4172.0/r.houghtransform/bin/r.
houghtransform: Permission denied
make: *** [r.houghtransform.tmp.html] Error 1
ERROR: Compilation failed, sorry. Please check above error messages.
(Fri Sep  7 04:01:33 2012) Command finished (8 sec) 

I guess it should not run "/bin/sh" on a binary.

[neteler]

Replying to neteler:

Here a test on Ubuntu with GRASS 7, via the wxGUI extension manager:

(Fri Sep  7 04:01:24 2012)                                                      
g.extension extension=r.houghtransform svnurl=http://svn.osgeo.org/grass/grass-addons/grass7

...

linesegmentsextractor.cpp:136:21: warning: conversion to ‘float’ from ‘double’ may alter its value [-Wconversion] /bin/sh: 1: /media/Proyectos/GISData_grass/South_america_cli mate_lonlat/Ortiz_j/.tmp/cito/4172.0/r.houghtransform/bin/r. houghtransform: Permission denied make: * [r.houghtransform.tmp.html] Error 1 ERROR: Compilation failed, sorry. Please check above error messages. (Fri Sep 7 04:01:33 2012) Command finished (8 sec) }}}

I guess it should not run "/bin/sh" on a binary.

The problem above seems to be Ubuntu related, it works ok on Fedora:

hough.cpp:111:10: warning: variable 'totsize' set but not
used [-Wunused-but-set-variable]
Installing...
Updating metadata file...
Installation of <r.houghtransform> successfully finished
(Fri Sep  7 13:49:58 2012) Command finished (8 sec)

[hamish]

neteler:

Is this problem solved as is bug #1406 ?

Replying to cmbarton:

I don't know where this is at currently. Has a new 'extension' variable been defined? I followed the discussion and see a good suggestion to resolving this, but don't know if anyone has actually done it.

see also #1762, "g.extension fails again on Mac"

current status on a Mac?

Hamish

[cmbarton]

I just compiled GRASS 7 in the past couple hours. g.extension still does not seem to work. I randomly tried to install i.rotate from the addons site using the addons interface in the GUI. Here is the result:

g.extension extension=i.rotate svnurl=http://svn.osgeo.org/grass/grass-addons/grass7
Fetching <i.rotate> from GRASS-Addons SVN (be patient)...
Compiling...
main.c:16:31: error: grass/config.h: No such file or
directory
main.c:23:23: error: grass/gis.h: No such file or directory
main.c:24:26: error: grass/raster.h: No such file or
directory
main.c:25:29: error: grass/gprojects.h: No such file or
directory
main.c:26:27: error: grass/glocale.h: No such file or
directory
main.c: In function 'main':
main.c:43: error: storage size of 'history' isn't known
main.c:49: warning: assignment makes pointer from integer
without a cast
main.c:53: error: dereferencing pointer to incomplete type
main.c:57: error: 'G_OPT_R_INPUT' undeclared (first use in
this function)
main.c:57: error: (Each undeclared identifier is reported
only once
main.c:57: error: for each function it appears in.)
main.c:57: warning: assignment makes pointer from integer
without a cast
main.c:58: error: 'G_OPT_R_OUTPUT' undeclared (first use in
this function)
main.c:58: warning: assignment makes pointer from integer
without a cast
main.c:59: warning: assignment makes pointer from integer
without a cast
main.c:60: error: dereferencing pointer to incomplete type
main.c:61: error: dereferencing pointer to incomplete type
main.c:62: error: dereferencing pointer to incomplete type
main.c:62: error: 'TYPE_DOUBLE' undeclared (first use in
this function)
main.c:63: error: dereferencing pointer to incomplete type
main.c:63: error: 'YES' undeclared (first use in this
function)
main.c:64: error: dereferencing pointer to incomplete type
main.c:65: error: dereferencing pointer to incomplete type
main.c:70: error: dereferencing pointer to incomplete type
main.c:71: warning: assignment makes pointer from integer
without a cast
main.c:76: warning: assignment makes pointer from integer
without a cast
main.c:77: error: dereferencing pointer to incomplete type
main.c:77: error: 'DCELL_TYPE' undeclared (first use in this
function)
main.c:93: error: 'DCELL' undeclared (first use in this
function)
main.c:93: error: expected ';' before 'd'
main.c:96: error: 'proj_info' undeclared (first use in this
function)
main.c:99: error: 'unit_info' undeclared (first use in this
function)
main.c:102: error: 'proj' undeclared (first use in this
function)
main.c:111: error: 'd' undeclared (first use in this
function)
main.c:111: error: expected expression before ')' token
main.c:123: error: dereferencing pointer to incomplete type
main.c:145: warning: dereferencing 'void *' pointer
main.c:147: error: expected expression before ')' token
main.c:157: error: 'outName' undeclared (first use in this
function)
main.c:16:31: error: grass/config.h: No such file or
directory
main.c:23:23: error: grass/gis.h: No such file or directory
main.c:24:26: error: grass/raster.h: No such file or
directory
main.c:25:29: error: grass/gprojects.h: No such file or
directory
main.c:26:27: error: grass/glocale.h: No such file or
directory
main.c: In function 'main':
main.c:43: error: storage size of 'history' isn't known
main.c:49: warning: assignment makes pointer from integer
without a cast
main.c:53: error: dereferencing pointer to incomplete type
main.c:57: error: 'G_OPT_R_INPUT' undeclared (first use in
this function)
main.c:57: error: (Each undeclared identifier is reported
only once
main.c:57: error: for each function it appears in.)
main.c:57: warning: assignment makes pointer from integer
without a cast
main.c:58: error: 'G_OPT_R_OUTPUT' undeclared (first use in
this function)
main.c:58: warning: assignment makes pointer from integer
without a cast
main.c:59: warning: assignment makes pointer from integer
without a cast
main.c:60: error: dereferencing pointer to incomplete type
main.c:61: error: dereferencing pointer to incomplete type
main.c:62: error: dereferencing pointer to incomplete type
main.c:62: error: 'TYPE_DOUBLE' undeclared (first use in
this function)
main.c:63: error: dereferencing pointer to incomplete type
main.c:63: error: 'YES' undeclared (first use in this
function)
main.c:64: error: dereferencing pointer to incomplete type
main.c:65: error: dereferencing pointer to incomplete type
main.c:70: error: dereferencing pointer to incomplete type
main.c:71: warning: assignment makes pointer from integer
without a cast
main.c:76: warning: assignment makes pointer from integer
without a cast
main.c:77: error: dereferencing pointer to incomplete type
main.c:77: error: 'DCELL_TYPE' undeclared (first use in this
function)
main.c:93: error: 'DCELL' undeclared (first use in this
function)
main.c:93: error: expected ';' before 'd'
main.c:96: error: 'proj_info' undeclared (first use in this
function)
main.c:99: error: 'unit_info' undeclared (first use in this
function)
main.c:102: error: 'proj' undeclared (first use in this
function)
main.c:111: error: 'd' undeclared (first use in this
function)
main.c:111: error: expected expression before ')' token
main.c:123: error: dereferencing pointer to incomplete type
main.c:145: warning: dereferencing 'void *' pointer
main.c:147: error: expected expression before ')' token
main.c:157: error: 'outName' undeclared (first use in this
function)
lipo: can't figure out the architecture type of: /var/folder
s/dm/x_m7msz48xj_9c0059b59rf00000gn/T//cc2vag11.out
make: *** [OBJ.x86_64-apple-darwin12.2.0/main.o] Error 1
ERROR: Compilation failed, sorry. Please check above error messages.

[cmbarton]

Markus asked me to check with r.fuzzy. It still doesn't work but gives a different error:

g.extension extension=r.fuzzy svnurl=http://svn.osgeo.org/grass/grass-addons/grass7
Fetching <r.fuzzy> from GRASS-Addons SVN (be patient)...
Compiling...
main.c: In function 'main':
main.c:149: warning: format not a string literal and no
format arguments
main.c:152: warning: format not a string literal and no
format arguments
main.c: In function 'main':
main.c:149: warning: format not a string literal and no
format arguments
main.c:152: warning: format not a string literal and no
format arguments
main.c: In function 'main':
main.c:50: warning: assignment from incompatible pointer
type
main.c: In function 'main':
main.c:50: warning: assignment from incompatible pointer
type
main.c: In function 'main':
main.c:62: warning: assignment from incompatible pointer
type
main.c:149: warning: format not a string literal and no
format arguments
main.c:153: warning: format not a string literal and no
format arguments
main.c:155: warning: format not a string literal and no
format arguments
main.c: In function 'main':
main.c:62: warning: assignment from incompatible pointer
type
main.c:149: warning: format not a string literal and no
format arguments
main.c:153: warning: format not a string literal and no
format arguments
main.c:155: warning: format not a string literal and no
format arguments
map_parser.c: In function 'parse_map_file':
map_parser.c:91: warning: format not a string literal and no
format arguments
map_parser.c: In function 'parse_map_file':
map_parser.c:91: warning: format not a string literal and no
format arguments
rule_parser.c: In function 'parse_rules':
rule_parser.c:132: warning: format not a string literal and
no format arguments
rule_parser.c: In function 'parse_rules':
rule_parser.c:132: warning: format not a string literal and
no format arguments
Installing...
make: *** No rule to make target `install'.  Stop.
WARNING: Installation failed, sorry. Please check above error messages.

[hamish]

how about for a shell script like r.in.onearth?

I take it Xcode is installed? (not sure what else is needed build-wise, but I'm guessing you already have it.. but does GRASS know where to look for it?)

Is there anything installed in $GISBASE/include/* ?

main.c:149: warning: format not a string literal and no
format arguments

Perhaps the above comes because it doesn't understand the _() gettext macros? (missing glocale.h)

Hamish

[cmbarton]

I compiled this particular binary with gettext support.

[hamish]

see also questions in comment 5 of #1762.

[cmbarton]

Yes. XCode is installed. I'm a binary maintainer and compile so I have to have it.

Michael

[kyngchaos]

I finally had a chance to look into this again. Simple mistake - the Mac install target for building GRASS was out of sync with the main install target and was missing the sed steps to update the installed Platform.make and Grass.make.

Should be fixed with r56408 (dev6) and r56409 (rel6), and hopefully r56410 (trunk). Please verify. There have been a lot of makefile changes in trunk that I haven't kept up with, and the Mac makefile needs an overhaul.

[kyngchaos]

Hmmm, there is one oddity here. letting it use the default prefix $GRASS_ADDON_PATH, which is the user ~/Library/GRASS/6.4/Modules/bin, the docs get put in the bin folder, ie ..../bin/docs/*

But if I manually set the prefix=~/Library/GRASS/6.4/Modules, it correctly puts both the executable in Modules/bin and the docs in Modules/docs. So if g.extension doesn't see a true prefix path, and it is a "bin" folder, maybe it should drop back one folder and check again?

And I just tried a script extension - it installs in Modules/scripts (manually set prefix). I don't have scripts in the Mac GRASS_ADDONS_PATH, and the Mac user menu building script doesn't check scripts to build the GUI addons menu. More updates needed, stay tuned...

P.S. I tested g.extension from the Terminal, not from the GUI.

[kyngchaos]

OK, script extensions now handled in Mac GRASS_ADDON_PATH and user menu build. r56412 (dev6), r56413 (rel6), r56414 (trunk)

[kyngchaos]

Thinking about the bin quirk, I wonder if I should just add Modules as the first path in GRASS_ADDON_PATH (in addition to Modules/bin and Modules/scripts) so g.extension sees it as a true prefix? Dropping back a folder from bin might not always be a safe thing to do.

Thoughts anyone?

[hamish]

Replying to kyngchaos:

Thinking about the bin quirk, I wonder if I should just add Modules as the first path in GRASS_ADDON_PATH (in addition to Modules/bin and Modules/scripts) so g.extension sees it as a true prefix? Dropping back a folder from bin might not always be a safe thing to do.

Thoughts anyone?

I don't exactly follow what the current behaviour is on OSX, so I'll just describe what it does on other UNIX,

scripts/ and bin/ should only exist during the build, g.extension installs all executables from there into GRASS_ADDON_PATH/ along side any of the users' personal addon scripts, then removes the empty build directories (if appropriate).

the point to install to e.g. ~/Library/ as GRASS_ADDON_PATH instead of the main GRASS install tree is that a) the user might not have permission to write to /Library/, and b) if the grass package is removed in an upgrade to a newer version, for scripts you don't want to have them deleted. (for compiled modules they would need to be rebuilt anyway if the ABI/API changed any)

does g.extension for Mac require Xcode? (so clang/llvm), or does your package ship a full gcc + gnu make? How does R handle that?

hope it helps somehow, Hamish

[kyngchaos]

I described how it worked for me, which looks like (from the code) it's a general case:

If the GRASS_ADDON_PATH is a bin folder, everything is put in that folder, including compiled commands, scripts and a docs folder with the help files.

If the GRASS_ADDON_PATH is not a bin folder, but a prefix with its own bin and docs subfolders, the compiled commands are put in bin, scripts are put in scripts and help files are put in docs. Scripts are NOT moved to bin.

[kyngchaos]

(meant to press preview)

It's not a question of whether to install to GRASS or a user folder. I understand that part.

I don't ship any developer tools. By default, R downloads from a pre-compiled binary repository, no Xcode needed, even for installation. If you want to compile extensions, then you need Xcode.

I did notice that g.extension still needs developer tools for script extensions, because it uses make to do the install part.

[cmbarton]

This is fixed in all current GRASS 7 versions. I assume that no one will fix in legacy GRASS 6. Closing