#1652: g.extension: provide option to use local source code instead of SVN
-------------------------------+--------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.0
Component: Installation | Version: unspecified
Keywords: g.extension addon | Platform: Unspecified
Cpu: Unspecified |
-------------------------------+--------------------------------------------
It would be a nice addition to g.extension to allow the use of local
source code (e.g. a local directory) for the installation of a module.
This would provide a unified way of installing extensions, even those one
does not, yet, see fit for public distribution.
#1652: g.extension: provide option to use local source code instead of SVN
-------------------------------+--------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.0
Component: Installation | Version: unspecified
Keywords: g.extension addon | Platform: Unspecified
Cpu: Unspecified |
-------------------------------+--------------------------------------------
Comment(by hamish):
? both source URL and compiled destination are configurable through the
svnurl= and prefix= options.
The GRASS_ADDON_PATH environment variable is also respected if it is set.
Is there something else which would be helpful to use beyond that?
e.g. avoid having to set svnurl=http://localhost/something and instead do
srcdir=/path/to/...? In that case why not just set up an alias:
alias gmake65='make MODULE_TOPDIR=/usr/src/grass/svn/grass65/'
and then run `gmake65` from your source dir?
Hamish
ps- I think it's a fine thing to use the addons repo as a module
incubation & development area; my method is to simply not activate the
Makefile until it's ready for wider consumption. see also the grass
sandbox repo for personal (but open) experimentation.
#1652: g.extension: provide option to use local source code instead of SVN
-------------------------------+--------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.0
Component: Installation | Version: unspecified
Keywords: g.extension addon | Platform: Unspecified
Cpu: Unspecified |
-------------------------------+--------------------------------------------
Comment(by mlennert):
Replying to [comment:1 hamish]:
> ? both source URL and compiled destination are configurable through the
svnurl= and prefix= options.
>
> The GRASS_ADDON_PATH environment variable is also respected if it is
set.
>
>
> Is there something else which would be helpful to use beyond that?
> e.g. avoid having to set svnurl=http://localhost/something and instead
do srcdir=/path/to/...? In that case why not just set up an alias:
> alias gmake65='make MODULE_TOPDIR=/usr/src/grass/svn/grass65/'
>
> and then run `gmake65` from your source dir?
>
Having a unified tool makes it easier for newbies. Using g.extension the
user does not have to think about MODULE_TOPDIR.
svnurl=http://localhost/something implies a web server on localhost, no ?
Again an unnecessary hurdle IMHO.
The question came up on the French user's list where someone would like to
use the r.traveltime addon which is not in svn. It would be nice to be
able to tell such a user to just download the .tgz, and then tell
g.extension where to find it and have g.extension handle the rest.
In this particular case, the authoer of the addon has agreed to put it on
the svn server which I hope to have the time for end of the week or next
week.
#1652: g.extension: provide option to use local source code instead of SVN
-------------------------------+--------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.0
Component: Installation | Version: unspecified
Keywords: g.extension addon | Platform: Unspecified
Cpu: Unspecified |
-------------------------------+--------------------------------------------
Comment(by wenzeslaus):
I've added a first draft of implementation of compilation of local source
code and its installation where it belongs. New code are few changes in
compilation function, new parameter and interception of standard flow and
executing the compile and install step without executing other things.
No error handling included. Except for MS Windows where it should fail.
But the interesting problem is that it should not fail for Python since
there is no reason for Python code to not be installed. But this requires
us to implement installation procedure of Python modules in Python instead
of Makefile.
Tested with a module in already downloaded SVN repository.
I've tested the proposed version of `g.extension` and it works for me on
both Ubuntu and Mac OS X. On Mac tested with both self-compiled and
installed GRASS (packaged by Michael Barton).
I did not checked on Mac but on Ubuntu it was installed to
`~/.grass7/addons` and the `modules.xml` file was not updated, I don't
know if this is OK or not and what is influenced.
In case of an error, there should be some suggestion to user to try to
install something from addons (some C module, e.g. r.geomorphon) to see if
the compilation works in general.
#1652: g.extension: provide option to use local source code instead of SVN
-----------------------------------------------------------------------+----
Reporter: mlennert | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.1.0
Component: Addons | Version: unspecified
Keywords: g.extension, addon, extensions, compilation, installation | Platform: Unspecified
Cpu: Unspecified |
-----------------------------------------------------------------------+----
Comment(by wenzeslaus):
As noted before, on MS Windows, Python modules could be compiled and this
relates to the solution of running Python on MS Windows problem where the
possible way is to use BAT files. `g.extension` run in this case would
generate the BAT file. `g.extension` can even generate BAT file and
Makefile itself since it is pretty clear what should be in them (this
applies even to C modules).