Re: [Plplot-devel] Splitting off libpltcl and greatly simplifying library linking options

[Alan W. I. <ir...@be...>]

On Thu, 25 Jul 2002, Vince Darley wrote:

> > |  As far as I know, no driver depends on anything in other drivers so
> > | that should not be an issue.
>
> This is untrue of the 'tk' driver.  While I am sure it is possible to
> remove any link-time dependencies through use of appropriate stubs,
> dispatch tables etc, actually using the tk driver uses the 'plframe'
> widget which in turn *requires* the xwin driver to operate.  Therefore it
> is meaningless to talk about the 'tk' driver unless the 'xwin' driver is
> available...
>
> (at least that's how I understand it).

That may be true, but I think the dependency is indirect via a library.
From my experiments, tk does not depend explicitly on any other driver.

I decided to check that empirical result using this adaptation of Joao's
bash commands

for i in nm -p drivers/tkd_drv.so | fgrep " U "| awk '{print $2}'; do nm -p \
drivers/xwind_drv.so | fgrep $i | fgrep " T "; done

there was no output which indicates there are no symbols in xwin_drv that
resolve undefined symbols in tk_drv.

Instead, as is natural, tk does depend on libplplot, and I presume it also
depends on libpltcltk (although I haven't checked).  Where we have to break
the vicious circle is to stop libraries depending on any drivers, and I
believe moving the 5 functions from xwin_drv to libpltcktk along the lines I
suggested will do the trick.

That brings up the similar question for tkwin.c.  Currently we have
in complete analogy with the xwin.c case, the following bad situation:

for i in nm -p libpltcld.so | fgrep " U "| awk '{print $2}'; do nm -p \
drivers/tkwind_drv.so | fgrep $i | fgrep " T "; done
000030f0 T PLColor_from_TkColor_Changed
00001804 T plD_open_tkwin
00002cb0 T pltkwin_setBGFG

As with xwin.c, I believe the solution here is to split out these functions
from tkwin.c into another file (tkwin_helper.c, say) whose compiled object
will go into libpltcltk.

I also notice that plD_open_tkwin calls GetVisual and AllocBGFG which are
defined locally in tkwin.c in direct analogy with plD_open_tkwin which calls
its versions of these locally defined functions in xwin.c.  Vince, are these
tkwin-defined versions of GetVisual and AllocBGFG identical to the xwin
definitions?  If so, when the 3 xwin.c functions are split out, they would
be able to use GetVisual and AllocBGFG already defined in xwin_helper.c and
put into libpltcltk as part of my proposal.  If the tkwin versions of
GetVisual and AllocBGFG are different from the xwin versions then we would
have to split them out also and give them different names to avoid a name
clash.

I emphasize all these tkwin.c splitting ideas are simply to give you food
for thought for now. All of this is vaporware until we prove that splitting
*xwin.c* solves the cross-linking problem in that case.  But currently it
looks like there is complete analogy between the xwin and tkwin cases so if
we find a solution for xwin, the solution for tkwin will soon follow.

Alan