#854 closed defect (fixed)
g.extension does not work on a Mac
Reported by: | cmbarton | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | 7.0.0 |
Component: | Addons | Version: | svn-releasebranch64 |
Keywords: | g.extension, addons | Cc: | martinl |
CPU: | All | Platform: | All |
Description
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)
Attachments (2)
Change History (40)
follow-ups: 2 3 comment:1 by , 15 years ago
comment:2 by , 15 years ago
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
comment:3 by , 15 years ago
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
comment:4 by , 14 years ago
Keywords: | g.extension added; extensions removed |
---|
comment:5 by , 13 years ago
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.
by , 13 years ago
Attachment: | g.extension.patch added |
---|
comment:6 by , 13 years ago
CPU: | OSX/Intel → All |
---|---|
Milestone: | 7.0.0 → 6.4.2 |
Version: | svn-trunk → 6.4.1 RCs |
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.
comment:7 by , 13 years ago
comment:8 by , 13 years ago
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.
follow-up: 12 comment:9 by , 13 years ago
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...
comment:11 by , 13 years ago
Looks much better than ever now. A remaining flaw is there:
- Linux binary snapshot taken from web site (I forced created some minutes ago)
- 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.
by , 13 years ago
Attachment: | Platform.make.diff added |
---|
Fixes for Platform.make *after* installation
follow-up: 13 comment:12 by , 13 years ago
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
follow-ups: 14 15 comment:13 by , 13 years ago
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.
comment:14 by , 13 years ago
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.
comment:15 by , 13 years ago
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.
comment:16 by , 13 years ago
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.
follow-up: 22 comment:19 by , 12 years ago
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
follow-up: 21 comment:20 by , 12 years ago
Milestone: | 6.4.2 → 6.4.3 |
---|---|
Version: | 6.4.1 RCs → svn-releasebranch64 |
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.
comment:21 by , 12 years ago
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)
comment:22 by , 11 years ago
Component: | Installation → Addons |
---|
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
comment:23 by , 11 years ago
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.
comment:24 by , 11 years ago
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.
comment:25 by , 11 years ago
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
comment:27 by , 11 years ago
Summary: | g.extension does not work on a Mac (probably not on Windows either → g.extension does not work on a Mac |
---|
see also questions in comment 5 of #1762.
comment:28 by , 11 years ago
Yes. XCode is installed. I'm a binary maintainer and compile so I have to have it.
Michael
comment:29 by , 11 years ago
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.
comment:30 by , 11 years ago
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.
comment:31 by , 11 years ago
follow-up: 33 comment:32 by , 11 years ago
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?
comment:33 by , 11 years ago
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
comment:34 by , 11 years ago
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.
comment:35 by , 11 years ago
(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.
comment:36 by , 8 years ago
Milestone: | 6.4.3 → 6.4.6 |
---|
comment:37 by , 6 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
This is fixed in all current GRASS 7 versions. I assume that no one will fix in legacy GRASS 6. Closing
comment:38 by , 6 years ago
Milestone: | 6.4.6 → 7.0.0 |
---|
Replying to cmbarton:
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).
Note: the correct OSX addons dir is /Library/Application Support/GRASS/7.0/Modules.