[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,
Hamish
--
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