[GRASS5] Library Issues

Glynn Clements glynn.clements at virgin.net
Mon Apr 15 04:31:43 EDT 2002


Radim Blazek wrote:

> > I've been analysing the interdependencies between the various GRASS
> > libraries, and wished to discuss some of the results.
> 
> > 3. There are three pairs of libraries which are mutually dependent:
> >
> > 	im_lib      |ex_lib
> > 	------------+------------
> > 	libgis.a    |libcoorcnv.a
> > 	libstubs.a  |libdbmi.a
> > 	libvect.a   |libdig2.a
> 
> > b)
> > 	libstubs.a references:
> > 	db_procedure_not_implemented
> >
> > 	libdbmi.a references:
> > 	db_driver_add_column
> ...
> > 	db_driver_update
> >
> > I haven't looked very far into this, but libdbmi probably needs to be
> > split into two separate libraries; a high-level library above the
> > drivers, which provides the API to clients, and a low-level library
> > which provides utilities for the drivers.
> 
> We can just move db_procedure_not_implemented() to libstubs.a, it
> is used only by other functions in that lib and should not be used 
> anywhere else.

The above dependency is the reason why I noticed the issue, but then
noticed that dbmi/lib/README says:

	This library contains routines called both by client and drivers.

The issue isn't worth fixing just for libstubs.a. It's only worth
dealing with if the library was going to be fully split into client
and driver libraries, so that you have something like:

	                      --> driver --
	                     /             \
	client --> libdbmi -<---> driver ---+-> libdbmi_drv
	                     \             /
	                      --> driver --

> > c)
> > 	libvect.a references:
> > 	dig_alloc_points
> ...
> > 	libdig2.a references:
> > 	dig_Rd_P_area
> 
> This is solved in 5.1, I would not recommend any changes in 5.0.

OK.

> > What is the distiction between libvect.a and libdig2.a? Should they be
> > combined? Or is all of this going to be replaced in 5.1?
> 
> In 5.0 it is more confused, in 5.1 I try to keep in vectlib all higher level 
> functions used by modules and in diglib all lower level functions like
> R/W portable format or low level functions for topology structure 
> modifications.

So, in 5.1, vectlib depends upon diglib but diglib no longer depends
upon vectlib?

-- 
Glynn Clements <glynn.clements at virgin.net>



More information about the grass-dev mailing list