[GRASS5] Library Issues

[Glynn Clements]

Radim Blazek wrote:

> > 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 --
> 
> Sorry, here I don't understand much. Just note that some routines are called 
> both by client and drivers, then it would be necessary to have 3 libes:
> common(shared), for drivers and for clients. I would left it all in one. What 
> is the problem with one big library? 

There isn't a problem at present. It may or may not present a problem
for shared libraries. In the worst case, it would just mean that
libdbmi couldn't be built as a shared library.

My original analysis was concerned with library dependencies, which
are an issue for shared libraries. It started from being unable to
build a shared libgis, due to the circular dependency between libgis
and libcoorcnv (coupled with the fact that, as it stood, libgis had
curses as a dependency because of G_edit_{cats,cellhd,history}).

Looking into it further, I found three sets of (apparent) mutual
dependencies, as noted in my original email. As it turns out, the
libdbmi -> libstubs dependency is largely bogus; libstubs just happens
to export many of the functions which libdbmi imports. The more
significant circular dependency is between libdbmi and the individual
drivers. However, the driver functions aren't in a library, so they
didn't show up in the analysis.

In short, I don't think that the dbmi case is particularly important. 
libgis has already been fixed, and vectlib/diglib may as well wait for
5.1

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