On 1 November 2012 12:29, Markus Neteler <neteler@osgeo.org> wrote:
On Wed, Oct 31, 2012 at 10:33 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:
>
> Moritz Lennert wrote:
>
>> > I suggest that modules should not simply be moved from addons to
>> > trunk, but that a developer has a close look at a module including
>> > testing before moving it to trunk.
>>
>> +1, but I see Martin's point about lack of dev power. So the trade-off
>> has to be between quality of code and value added of having a
>> functionality in trunk even if the code is not perfect.
>
> Relegating something to add-ons is a reliable way to reduce the amount
> of developer oversight it gets. E.g. currently you can't just "make"
> the add-ons/grass7 directory (it lacks a Makefile),
Now there is.
Thanks !
> so most developers
> won't even try to compile it. If the modules were in trunk, developers
> may notice errors or warnings as part of the normal build process.
Agreed.
I also think that we need the toolbox concept rather at GUI level than
at directory level.
+1 there was an earlier discussion about using modules keywords to make
module groups...
> Relegating something to add-ons is a reliable way to reduce the amount
> of developer oversight it gets. E.g. currently you can't just "make"
> the add-ons/grass7 directory (it lacks a Makefile),
Now there is.
r53636 fixes a couple of issues with the r.in.wms2 and v.in.wfs2
Makefiles. From the add-ons/grass7 directory, you can do e.g.:
make MODULE_TOPDIR=$GISBASE
to build everything using the include/Make/*.make files from GRASS
7 (either installed or the dist.<arch> directory).
imagery/i.vi.mpi requires mpicc. This should probably be a separate
variable, e.g. $(MPICC).
vector/v.in.redwg requires LIBREDWGLIBPATH and LIBREDWGINCPATH to have
any necessary -L/-I switches for libredwg and dwg.h.
On 1 November 2012 23:34, Glynn Clements <glynn@gclements.plus.com> wrote:
Markus Neteler wrote:
> > Relegating something to add-ons is a reliable way to reduce the amount
> > of developer oversight it gets. E.g. currently you can't just "make"
> > the add-ons/grass7 directory (it lacks a Makefile),
>
> Now there is.
r53636 fixes a couple of issues with the r.in.wms2 and v.in.wfs2
Makefiles. From the add-ons/grass7 directory, you can do e.g.:
make MODULE_TOPDIR=$GISBASE
Thanks, including addons SVN in my daily compile... How could we auto-load
those additional modules in their GUI menu groups?
to build everything using the include/Make/*.make files from GRASS
7 (either installed or the dist.<arch> directory).
imagery/i.vi.mpi requires mpicc. This should probably be a separate
variable, e.g. $(MPICC).
to be set as a configure file option?
vector/v.in.redwg requires LIBREDWGLIBPATH and LIBREDWGINCPATH to have
any necessary -L/-I switches for libredwg and dwg.h.
Relegating something to add-ons is a reliable way to reduce the amount
of developer oversight it gets. E.g. currently you can't just "make"
the add-ons/grass7 directory (it lacks a Makefile), so most developers
won't even try to compile it. If the modules were in trunk, developers
may notice errors or warnings as part of the normal build process.
btw, there are logs from WinGRASS AddOns packaging available online [1].
> r53636 fixes a couple of issues with the r.in.wms2 and v.in.wfs2
> Makefiles. From the add-ons/grass7 directory, you can do e.g.:
>
> make MODULE_TOPDIR=$GISBASE
>
Thanks, including addons SVN in my daily compile... How could we auto-load
those additional modules in their GUI menu groups?
AFAIK, at present you need to edit menudata.xml.
> to build everything using the include/Make/*.make files from GRASS
> 7 (either installed or the dist.<arch> directory).
>
> imagery/i.vi.mpi requires mpicc. This should probably be a separate
> variable, e.g. $(MPICC).
to be set as a configure file option?
Once it's moved into trunk, configure checks should be added. Until
then, it should just define a variable which can be overridden on the
command line.
Currently, it uses CC, which is problematic. Uusing CC=mpicc on the
command line would cause all C code to be compiled using mpicc, while
using e.g. CC=gcc on the command line would override the setting in
i.vi.mpi/Makefile.
A fundamental property of "make" is that variables set on the command
line override settings within a Makefile, so every Makefile variable
is effectively a command-line parameter with a default value.
On 2 November 2012 22:35, Glynn Clements <glynn@gclements.plus.com> wrote:
Yann Chemin wrote:
> > r53636 fixes a couple of issues with the r.in.wms2 and v.in.wfs2
> > Makefiles. From the add-ons/grass7 directory, you can do e.g.:
> >
> > make MODULE_TOPDIR=$GISBASE
> >
>
> Thanks, including addons SVN in my daily compile... How could we
auto-load
> those additional modules in their GUI menu groups?
AFAIK, at present you need to edit menudata.xml.
OK, I will see how to modify this one
> > to build everything using the include/Make/*.make files from GRASS
> > 7 (either installed or the dist.<arch> directory).
> >
> > imagery/i.vi.mpi requires mpicc. This should probably be a separate
> > variable, e.g. $(MPICC).
>
> to be set as a configure file option?
Once it's moved into trunk, configure checks should be added. Until
then, it should just define a variable which can be overridden on the
command line.
Currently, it uses CC, which is problematic. Uusing CC=mpicc on the
command line would cause all C code to be compiled using mpicc, while
using e.g. CC=gcc on the command line would override the setting in
i.vi.mpi/Makefile.
A fundamental property of "make" is that variables set on the command
line override settings within a Makefile, so every Makefile variable
is effectively a command-line parameter with a default value.
> Relegating something to add-ons is a reliable way to reduce the amount
> of developer oversight it gets. E.g. currently you can't just "make"
> the add-ons/grass7 directory (it lacks a Makefile), so most developers
> won't even try to compile it. If the modules were in trunk, developers
> may notice errors or warnings as part of the normal build process.
btw, there are logs from WinGRASS AddOns packaging available online [1].
g.cloud.py imports pexpect (which isn't part of the standard library)
but doesn't use it. cloud_ssh.py does use pexpect for scripting "ssh".
It appears to be doing this primarily so that it can feed it a
password, which is a bad idea (use ssh-agent if you want to be able to
use ssh without having to provide a password).
Also: includes a couple of shell scripts. cloud_collect.sh deals with
GRASS and could probably be converted to Python. cloud_mail.sh relies
upon a command-line "mail" program which is not particularly portable.
imagery/i.vi.mpi:
mpicc: command not found
raster/r.agent:
make: *** No targets specified and no makefile found. Stop.
raster/r.convert:
make: *** No targets specified and no makefile found. Stop.
On Sat, Nov 3, 2012 at 6:29 PM, Glynn Clements <glynn@gclements.plus.com> wrote:
...
general/g.cloud:
ImportError: No module named pexpect
g.cloud.py imports pexpect (which isn't part of the standard library)
but doesn't use it. cloud_ssh.py does use pexpect for scripting "ssh".
It appears to be doing this primarily so that it can feed it a
password, which is a bad idea (use ssh-agent if you want to be able to
use ssh without having to provide a password).
Also: includes a couple of shell scripts. cloud_collect.sh deals with
GRASS and could probably be converted to Python. cloud_mail.sh relies
upon a command-line "mail" program which is not particularly portable.
Luca Delucchi and me will work on this.
...
raster/r.agent:
make: *** No targets specified and no makefile found. Stop.
This is slow work in progress (the author and me). The Makefile will be
added once the module starts to become usable.
raster/r.convert:
make: *** No targets specified and no makefile found. Stop.
Also: consists entirely of shell scripts.
Hamish's script for a new raster directory layout in GRASS. Likely
not happening in GRASS7, so better don't add a Makefile to avoid
a mess for "innocent" users.