[GRASS5] grass51

[Markus Neteler]

Hi Radim, hi all,

On Thu, Dec 28, 2000 at 11:33:32AM +0100, Radim Blazek wrote:
> Hi all,
> 
> some questions, proposals, wishes for grass51 repository:
> 
> 1) To enable 5.1 development without commiting all source into repository
>     (branching is impossible because structure is changed)
>     I have written script link:
> 
>     Usage: link [options]
>     Options
>     -old=DIR   grass 5.0 source directory (required)
>     -new=DIR   grass 5.1 source directory (default is ..)
>     -map=FILE  file mapping old directory structure to new
>            (default is ./link.conf)
> 
>   which creates symbolic links from grass51 local copy to grass50 local copy
>   according to definition in link.conf file:
>   
>    src/include/*       include
>    src/libes/gis       lib/gis
> 
>   With such system we could bugfix in grass5 as long as possible (until part of code
>   will be changed to grass51)  and also  test new structure easily.
>   If no objections I will commit into grass51/tools.

Please commit - your suggestion is very reasonable and will support
the transition to GRASS 5.1 without breaking everything.

> 2) Proposal for commiting new directories into grass51 (nothing new):
>     (I use names: grass51/1.level dir/2.level dir)
>     - only Marcus may add 1.level dirs
>     - both 1. and 2. level dirs MUST be discussed before adding into repository
I agree - especially with second proposal: discussion!
 
> 3) Can somebody explain better "New concepts: - the I/O routines should be 
>     removed from src/libes/gis...." in documents/new_directory_structure.txt?
>     (Frank Warmerdams?)
>     Is it necessary to extract non I/O routines from library? In
>     vect32/Vlib we have mixed I/O routines with non I/O for example
>     (Vect_read_next_line() and Vect_get_point_in_area()). That would be
>     huge work.  How should look like new directory structure? Separated
>     GPL and LGPL libes?
Soory for this confusion: I/O means here:
Import to GRASS and export from GRASS. No internal data transfer.

Well, I was thinking of having the import/export routines into a separate
directory as Frank W. already programs with "libgrass" (currently limited to
GRASS raster import/export). If we have the import/export library routines
separated from the general gis routines in an own directory, we can release
them under LGPL license to allow proprietry software to add direct GRASS
support. As we don't want to give away the GIS library under LGPL, just the
import/export functions should be separated in a sort of IM_EXP_LIB
(like GISLIB).
Hope this clarifies?!

> 4) Some directory names for discussion before checking in 
>     (see documents/new_directory_structure.txt): 
>     Marcus, could you check in after discussion?
>     -  grass51/include
>     -  grass51/lib             ?, see 3)
here we will have several subdirectories as before, I think.

>     -  grass51/display    
>     -  grass51/vector
>     -  grass51/doc(ument)(s)    
>              
>     grass51/base/display,vector  is proposed in
>     new_directory_structure.txt but I thing that most important modules
>     should be in 1. level dirs not lower in structure than less important
>     modules.
> 
> 5)  Where should be placed v.in.ascii directory (contains both v.in.ascii
>      and v.out.ascii module)?  Into vector, convert, import or export?
>      Probably rename to v.ascii?
Perhaps we concentrate all import tools in
/import
and all export tools in
/export?

Or: have then together according to their function like
exchange/v.ascii    # includes v.in.ascii, v.out.ascii
exchange/v.shape    # includes v.in.shape, v.out.shape
..

Maybe the second idea is better.
   
> 7)  Could somebody who know how to do that write and commit new
>      configure/make system. (According to my experience to compile new
>      structure with old system is impossible.)
Eric Mitchell? Please send some recommendations...

Markus

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'