[GRASS5] grass51

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.

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

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?

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)
    - 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?
  
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.)

I am waiting for your comments.

Radim

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

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@geog.uni-hannover.de with
subject 'unsubscribe grass5'