[GRASS-dev] [GRASS GIS] #854: g.extension does not work on a Mac

GRASS GIS trac at osgeo.org
Sun May 26 05:00:45 PDT 2013

#854: g.extension does not work on a Mac
 Reporter:  cmbarton             |       Owner:  grass-dev@…              
     Type:  defect               |      Status:  new                      
 Priority:  normal               |   Milestone:  6.4.3                    
Component:  Addons               |     Version:  svn-releasebranch64      
 Keywords:  g.extension, addons  |    Platform:  All                      
      Cpu:  All                  |  

Comment(by hamish):

 Replying to [comment:32 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,

Ticket URL: <https://trac.osgeo.org/grass/ticket/854#comment:33>
GRASS GIS <http://grass.osgeo.org>

More information about the grass-dev mailing list