Hi all,
currently wxGUI code is placed by building system in `etc` directory.
I would say that more appropriate would be to put `gui` directory into
root, so at the same level as `bin` or `scripts`.
Simirarly python libs are placed also in `etc` directory. They should
probably go to `lib\python` instead of `etc\python`.
Any opinion?
Martin
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
On Thu, Apr 17, 2014 at 2:59 PM, Martin Landa <landa.martin@gmail.com>wrote:
Hi all,
currently wxGUI code is placed by building system in `etc` directory.
I would say that more appropriate would be to put `gui` directory into
root, so at the same level as `bin` or `scripts`.Simirarly python libs are placed also in `etc` directory. They should
probably go to `lib\python` instead of `etc\python`.Any opinion?
I'm for the reform. Please, consider also other related issues.
The same layout for src and dist would be good for editing because then
editors, python and other tools can just use the layout in src and it will
work. This would mean that things which are now in `lib/python` should go
to something which is named `grass` so that I can do
import grass.script
in the source code and it will work. Maybe separate directory for python
libs in src root would enable this option?
Note that for C/C++ code we have a similar issue. In the source code,
includes are in `include` but in distribution they are in `include/grass`
so you have to do
#include grass/raster.h
but if you are editing source code in some clever editor and you want to
jump from the .c file to the header, you cannot since there is no `grass`
directory in src. This applies also for code completion etc. Of course, you
can set the editor so that it finds the files in dist but you don't want to
jump to dist, but to source code.
Vaclav
Martin
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Am 2014-04-17 21:30, schrieb Vaclav Petras:
On Thu, Apr 17, 2014 at 2:59 PM, Martin Landa <landa.martin@gmail.com
<mailto:landa.martin@gmail.com>> wrote:Hi all,
currently wxGUI code is placed by building system in `etc` directory.
I would say that more appropriate would be to put `gui` directory into
root, so at the same level as `bin` or `scripts`.Simirarly python libs are placed also in `etc` directory. They should
probably go to `lib\python` instead of `etc\python`.Any opinion?
I'm for the reform. Please, consider also other related issues.
The same layout for src and dist would be good for editing because then
editors, python and other tools can just use the layout in src and it
will work. This would mean that things which are now in `lib/python`
should go to something which is named `grass` so that I can doimport grass.script
in the source code and it will work. Maybe separate directory for python
libs in src root would enable this option?Note that for C/C++ code we have a similar issue. In the source code,
includes are in `include` but in distribution they are in
`include/grass` so you have to do#include grass/raster.h
but if you are editing source code in some clever editor and you want to
jump from the .c file to the header, you cannot since there is no
`grass` directory in src. This applies also for code completion etc. Of
course, you can set the editor so that it finds the files in dist but
you don't want to jump to dist, but to source code.Vaclav
Martin
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
I warmly welcome this advance! So far Fedora manipulates various paths, including man page and lib location. Please see https://trac.osgeo.org/grass/ticket/1610
Greetings, Volker
Hi,
2014-04-17 21:30 GMT+02:00 Vaclav Petras <wenzeslaus@gmail.com>:
I'm for the reform. Please, consider also other related issues.
great 
The same layout for src and dist would be good for editing because then
editors, python and other tools can just use the layout in src and it will
work. This would mean that things which are now in `lib/python` should go to
something which is named `grass` so that I can do
So if you agree I will start with
1) etc/gui -> gui
2) etc/python -> lib/python
Martin
On Fri, Apr 18, 2014 at 10:44 AM, Martin Landa <landa.martin@gmail.com>wrote:
> The same layout for src and dist would be good for editing because then
> editors, python and other tools can just use the layout in src and it
will
> work. This would mean that things which are now in `lib/python` should
go to
> something which is named `grass` so that I can doSo if you agree I will start with
1) etc/gui -> gui
2) etc/python -> lib/python
I'm still not sure what is the right solution for import problems. Now I
really cannot do all the tests but it would be better to it before 2). I
think you should be able to run Python libraries and modules when you set
PYTHONHOME to some directory in source code. From quick look it seems that
`lib/python` in src should be moved to `lib/python/grass` but than grass
would be the only directory in `lib/python`.
Vaclav Petras wrote:
Note that for C/C++ code we have a similar issue. In the source code,
includes are in `include` but in distribution they are in `include/grass`
so you have to do#include grass/raster.h
but if you are editing source code in some clever editor and you want to
jump from the .c file to the header, you cannot since there is no `grass`
directory in src. This applies also for code completion etc. Of course, you
can set the editor so that it finds the files in dist but you don't want to
jump to dist, but to source code.
All other factors being equal, moving include/* to include/grass/*
would be a good thing. We've made similar moves in the past, e.g.
gisdefs.h -> defs/gis.h, lib/python/*.py -> lib/python/script/*.py.
Did these cause any particular problems?
You may be able to trick an IDE by adding a symlink, e.g.
ln -s . include/grass
so that include/grass is a symlink to include.
One thing to bear in mind: if the source and staging (dist.$arch)
versions of a file differ, it's the staging version which is actually
used for compilation and linking.
Essentially, a module or library which depends upon some other library
uses the installed version of the dependency, for some value of
"installed" (either the staging version or, if you override GISBASE,
the really-installed version)
This allows you to build most of GRASS, install it, "make clean", then
subsequently build extra modules against the installed version, rather
than having to build everything from scratch.
--
Glynn Clements <glynn@gclements.plus.com>
On Thu, Apr 17, 2014 at 3:30 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
On Thu, Apr 17, 2014 at 2:59 PM, Martin Landa <landa.martin@gmail.com>wrote:
Hi all,
currently wxGUI code is placed by building system in `etc` directory.
I would say that more appropriate would be to put `gui` directory into
root, so at the same level as `bin` or `scripts`.Simirarly python libs are placed also in `etc` directory. They should
probably go to `lib\python` instead of `etc\python`.Any opinion?
I'm for the reform. Please, consider also other related issues.
The same layout for src and dist would be good for editing because then
editors, python and other tools can just use the layout in src and it will
work. This would mean that things which are now in `lib/python` should go
to something which is named `grass` so that I can doimport grass.script
in the source code and it will work. Maybe separate directory for python
libs in src root would enable this option?Note that for C/C++ code we have a similar issue. In the source code,
includes are in `include` but in distribution they are in `include/grass`
so you have to do#include grass/raster.h
but if you are editing source code in some clever editor and you want to
jump from the .c file to the header, you cannot since there is no `grass`
directory in src. This applies also for code completion etc. Of course, you
can set the editor so that it finds the files in dist but you don't want to
jump to dist, but to source code.
Another reason for having src and dist code with the same layout in case of
Python is the documentation. The Doxygen is currently quite messy:
http://grass.osgeo.org/programming7/namespaces.html
contains grass, python, all GUI packages/namespaces individually and few
others
http://grass.osgeo.org/programming7/namespacegrass.html
contains script and temporal but they are different from those in python
http://grass.osgeo.org/programming7/namespacepython.html
contains what is in src/lib/python
Vaclav
Martin
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Vaclav:
currently wxGUI code is placed by building system in `etc`
directory. I would say that more appropriate would be to put `gui`
directory into root, so at the same level as `bin` or `scripts`.Simirarly python libs are placed also in `etc` directory. They
should probably go to `lib\python` instead of `etc\python`.
probably not $GISBASE/lib/python/, as lib/ is for libgis et al. on UNIX
systems.
$GISBASE/python/grass/, or however python likes it, would be more
appropriate.
Martin:
> in the source code and it will work. Maybe separate directory for
> python libs in src root would enable this option?
mmph, I think the basic src layout is ok, and $SRC/lib/python/ is where
it is logically expected to be in the source.
> Note that for C/C++ code we have a similar issue. In the source
> code, includes are in `include` but in distribution they are in
> `include/grass` so you have to do
>
> #include grass/raster.h
that's exactly how it should be, no?
> but if you are editing source code in some clever editor and you
> want to jump from the .c file to the header, you cannot since there
> is no `grass` directory in src. This applies also for code
> completion etc.
maybe the editor program isn't as clever as it could be 
10 minutes of setup only has to be done once, and could be documented
in the wiki.
Another reason for having src and dist code with the same layout in
case of Python is the documentation. The Doxygen is currently quite
messy:http://grass.osgeo.org/programming7/namespaces.html
contains grass, python, all GUI packages/namespaces individually and
few othershttp://grass.osgeo.org/programming7/namespacegrass.html
contains script and temporal but they are different from those in
pythonhttp://grass.osgeo.org/programming7/namespacepython.html
contains what is in src/lib/python
I'm sure there will be a programmatic way around that.
that is, Debian ships on 11 different hardware platforms or so, so
platform independent files are split off into platform=all packages and
shared between all platforms. since $GISBASE/etc/ is a mix of binaries
and scripts it takes a lot of close work to make sure everything gets
to where it needs to be for debian's particular rules (/var/lib/grass or
/usr/lib/grass). this is a lot cleaner in trunk already.
mv $GISBASE/etc/gui $GISBASE/
mv $GISBASE/etc/python $GISBASE/
seems ok to me. (although to be honest I don't really care)
I notice $GISBASE/share/applications/grass.desktop, which seems silly.
Just put it in gui/icons/ with the rest and let the packaging scripts
move it to where it needs to be.
regards,
Hamish
--
Hamish <hamish.webmail@gmail.com>
.
Thought I should join the Yahoo mail diaspora before 30 days
worth of my emails got flushed from everyone's spam boxes never
to be seen again. In the last weeks some have made it to the ML
archives at least, if not to end recipients. Others seem to have
just disappeared into /dev/null. It didn't help that the web
interface had become an unusable gibberish of broken JavaScript
and their IMAP would only transfer the oldest 4% of my inbox.
.
http://www.ietf.org/mail-archive/web/ietf/current/msg87153.html
http://www.spamresource.com/2014/04/up-in-arms-about-yahoos-dmarc-policy.html
http://wiki.list.org/pages/viewpage.action?pageId=17891458
Hamish wrote:
>>> currently wxGUI code is placed by building system in `etc`
>>> directory. I would say that more appropriate would be to put `gui`
>>> directory into root, so at the same level as `bin` or `scripts`.
>>>
>>> Simirarly python libs are placed also in `etc` directory. They
>>> should probably go to `lib\python` instead of `etc\python`.probably not $GISBASE/lib/python/, as lib/ is for libgis et al. on UNIX
systems.
Note that the Python standard library typically goes into
/usr/lib/pythonX.Y (where X.Y is the version) on Unix.
OTOH, the standard library includes DSOs as well as .py/.pyc files,
wheres GRASS' Python libraries are pure Python.
> > Note that for C/C++ code we have a similar issue. In the source
> > code, includes are in `include` but in distribution they are in
> > `include/grass` so you have to do
> >
> > #include grass/raster.hthat's exactly how it should be, no?
Well, there should be <angle brackets> around the name, but having the
directory as part of the header name is intentional.
The point was that the "source" versions of the header files don't
live in a parent directory called "grass".
The suggestion is to move all of the header files and subdirectories
(except perhaps the "Make" directory) into a "grass" subdirectory, so
that the source layout mirrors the installed layout.
At the same time, we might want to reconsider whether the "Make"
directory really belongs in "include".
--
Glynn Clements <glynn@gclements.plus.com>
Hi,
2014-04-18 16:44 GMT+02:00 Martin Landa <landa.martin@gmail.com>:
1) etc/gui -> gui
for record, I moved wxGUI to DISTDIR/gui in r60006-13. I also
eliminated hardcoded paths wxGUI code by adding wxpython dir to
PYTHONPATH. You can report possible bug related to this change
directly to me. Later I would to introduce this change also to
relbr70.
Martin
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
Hi,
2014-04-30 9:08 GMT+02:00 Glynn Clements <glynn@gclements.plus.com>:
probably not $GISBASE/lib/python/, as lib/ is for libgis et al. on UNIX
systems.Note that the Python standard library typically goes into
/usr/lib/pythonX.Y (where X.Y is the version) on Unix.OTOH, the standard library includes DSOs as well as .py/.pyc files,
wheres GRASS' Python libraries are pure Python.
speaking directly, what you would suggest?
1) etc/python -> lib/python
2) etc/python -> lib/python2
3) etc/python -> python
4) etc/python -> python2
Do we need separated python3 libs later in the future when we support
Python3? Probably, yes if we support still Python2. Martin
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
Martin Landa wrote:
>> probably not $GISBASE/lib/python/, as lib/ is for libgis et al. on UNIX
>> systems.
>
> Note that the Python standard library typically goes into
> /usr/lib/pythonX.Y (where X.Y is the version) on Unix.
>
> OTOH, the standard library includes DSOs as well as .py/.pyc files,
> wheres GRASS' Python libraries are pure Python.speaking directly, what you would suggest?
1) etc/python -> lib/python
2) etc/python -> lib/python2
3) etc/python -> python
4) etc/python -> python2
Maybe share/python?
If anything needs to move, it's the executables which are currently in
etc (I believe that "libexec" is the standard directory for
executables which aren't supposed to be executed directly by the
user).
Do we need separated python3 libs later in the future when we support
Python3? Probably, yes if we support still Python2. Martin
Not necessarily. It's intended to be possible to write code which
works with either 2 or 3, although some features would require 2.7. If
we need to support both 2.6 and 3.x, then we'd probably need two
versions (you can't just use conditionals, because some features
affect the parser).
--
Glynn Clements <glynn@gclements.plus.com>