[GRASS5] Library Issues

[Glynn Clements]

I've been analysing the interdependencies between the various GRASS
libraries, and wished to discuss some of the results.

1. The following symbols are referenced in libimage_sup.a, but don't
appear to be defined anywhere:

	symbol             |object
	-------------------+-------------
	mark_control       |photo_init.o
	Menu_msg           |ltm_anal.o
	Menu_msg           |photo_anal.o
	Menu_msg           |poly_anal.o
	read_elev          |ltm_anal.o
	read_elev          |ltm_trans.o
	read_elev          |photo_anal.o
	read_elev          |photo_trans.o
	select_current_env |convert_ll.o
	select_target_env  |convert_ll.o

Can anyone shed any light on this? Are they meant to be defined by the
application? If so, the interface should probably be changed to use an
explicit callback.

There are also a number of undefined symbols in libgeo.a:

	D_ask_driver_raw
	D_clear_driver
	D_cursor_buttons
	D_foot_switch
	D_get_scale
	D_read_raw
	D_setup_driver
	D_setup_origin
	D_start_button

It appears that these are meant to be provided by a "driver" (although
the only implementation which I can find is src.contrib/OTHER/numonics).
Is this the case?

2. A significant number of global symbols are defined in multiple
libraries; in particular, the following are defined in both libortho.a
and libimage_sup.a:

	I_ask_camera_any
	I_ask_camera_new
	I_ask_camera_old
	I_compute_ortho_equations
	I_find_camera
	I_find_initial
	I_get_con_points
	I_get_group_camera
	I_get_group_elev
	I_get_ref_points
	I_inverse_ortho_ref
	I_list_cameras
	I_new_con_point
	I_new_ref_point
	I_ortho_ref
	I_put_con_points
	I_put_group_camera
	I_put_group_elev
	I_put_ref_points
	I_read_con_points
	I_read_ref_points
	I_write_con_points
	I_write_ref_points

The following symbols are also multiply defined:

	symbol      |object       |library
	------------+-------------+--------------
	Bugs2       |error.o      |libimage_sup.a
	Bugs2       |error.o      |libortho.a
	I_georef    |georef.o     |libI.a
	I_georef    |georef.o     |libortho.a
	inverse     |m_inverse.o  |libortho.a
	inverse     |inverse.o    |libtrans.a
	isnull      |isnull.o     |libortho.a
	isnull      |inverse.o    |libtrans.a
	m_add       |matrix_ops.o |libimage_sup.a
	m_add       |m_add.o      |libortho.a
	matrix_error|ref_ortho.o  |libimage_sup.a
	matrix_error|orthoref.o   |libortho.a
	m_copy      |matrix_ops.o |libimage_sup.a
	m_copy      |m_copy.o     |libortho.a
	m_mult      |matrix_ops.o |libimage_sup.a
	m_mult      |m_mult.o     |libortho.a
	m_mult      |m_mult.o     |libtrans.a
	transpose   |jacobi.o     |libgmath.a
	transpose   |m_transpose.o|libortho.a

Can someone who is familiar with the imagery code look into the
apparent duplication, and whether it can be eliminated?

The matrix stuff will ultimately be handled by the gmath library.

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

a)
	libgis.a references:
	CC_datum_name
	CC_datum_shift
	CC_get_datum_by_name

	libcoorcnv.a references:
	G_realloc
	G_fatal_error
	G_warning
	G_ellipsoid_name
	G_get_ellipsoid_by_name
	G_get_spheroid_by_name
	G_getl
	G_gisbase
	G_store
	G_strcasecmp
	G_strcat
	G_strcpy
	G_strip

The obvious solution is to move coorcnv/datum.c into libgis.

b)
	libstubs.a references:
	db_procedure_not_implemented

	libdbmi.a references:
	db_driver_add_column
	db_driver_bind_update
	db_driver_close_cursor
	db_driver_close_database
	db_driver_create_database
	db_driver_create_index
	db_driver_create_table
	db_driver_delete
	db_driver_delete_database
	db_driver_describe_table
	db_driver_drop_column
	db_driver_drop_index
	db_driver_drop_table
	db_driver_execute_immediate
	db_driver_fetch
	db_driver_find_database
	db_driver_finish
	db_driver_init
	db_driver_insert
	db_driver_list_databases
	db_driver_list_indexes
	db_driver_list_tables
	db_driver_open_database
	db_driver_open_insert_cursor
	db_driver_open_select_cursor
	db_driver_open_update_cursor
	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.

c)
	libvect.a references:
	dig_alloc_points
	dig_bound_box2
	dig__fill_head_portable
	dig__fread_port_C
	dig__fread_port_D
	dig__fread_port_I
	dig__fread_port_L
	dig__fwrite_port_C
	dig__fwrite_port_D
	dig__fwrite_port_I
	dig__fwrite_port_L
	dig__Init_portable_code
	dig_load_plus
	dig_new_to_old_type
	dig_old_to_new_type
	dig_point_in_poly
	dig__set_cur_in_head
	dig__set_cur_out_head
	dig_struct_copy
	dig_x_Rd_P_area
	dig_x_Rd_P_att
	dig_x_Rd_P_isle
	dig_x_Rd_P_line
	dig_x_Rd_Plus_head
	dig_x_Rd_P_node
	dig_x_Wr_P_area
	dig_x_Wr_P_att
	dig_x_Wr_P_isle
	dig_x_Wr_P_line
	dig_x_Wr_Plus_head
	dig_x_Wr_P_node

	libdig2.a references:
	dig_Rd_P_area
	dig_Rd_P_att
	dig_Rd_P_isle
	dig_Rd_P_line
	dig_Rd_Plus_head
	dig_Rd_P_node
	dig_Wr_P_area
	dig_Wr_P_att
	dig_Wr_P_isle
	dig_Wr_P_line
	dig_Wr_Plus_head
	dig_Wr_P_node
	V2_read_line

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?

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