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 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 I'm sure there will be a programmatic way around that. fyi, from the DebianGIS packaging TODO: ===== * The grass 'etc' directory contains a mixed arch/non-arch depending mess of files. They should be automatically classified in the install target and moved to /var/lib/grass or /usr/lib/grass, leaving symlinks so to not break things. ===== 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.webm...@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 _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev