Much of this is relics from the old digitizing and air photo routines.
Some
date back as far as FHIS if memory serves me correctly. It's hard code
for specific (and non-exsistant anymore) devices. Most of this can I
think
safely go away, but there are some global calls that should remain. I
remember this from hacking up r.nntool. I will try and dig up my notes
on what is/was junk.
Bruce
-----Original Message-----
From: Glynn Clements
Sent: Fri 4/12/2002 5:45 AM
To: grass5@grass.itc.it
Cc:
Subject: [GRASS5] Library Issues
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@virgin.net>
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5