Re: [Plplot-devel] tkwin doesn't work as dynamic driver :(

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

On Fri, 12 Jul 2002, Vince Darley wrote:

> Try putting plplotter.c in the tiny dll with tkwin.c...
>

I think that might work. Here is my best guess at the mental model of the
linking, subject to correction by the experts here.

(a) You would need some tcl/tk mechanism to dlopen that combined dll.  I
assume that would be where TEA came in.

(b) the dll itself would be linked to libplplot as a shared library so that
library gets automatically loaded as well.  (At least that is what seems
to happen for the python plplot extension module which is a dll that calls
libplplot functions).

(c) libplplot has calls to tkwin.o itself which it would dlopen according to
the dynamic driver mechanism in plcore.c.  Under python this just works, and
I assume the same would be true under tcl/tk except the dlopen would
automatically turn into an effective no-op since that dll would have already
been loaded by the tcl dlopen.

(d) libplplot is currently linked against the shared libtclmatrix library.
From our recent experience with "load libplplotd.so Plplotter" under wish
that linking against libtclmatrix is all that is required to make the
libtclmatrix functions available to the tcl examples that were run under
wish with runAllDemos.tcl.

So I think this linking scenario you suggest would work.

However, IMO a much better idea is to split off everything (not just
plplotter.o) concerning tcl/tk helper functions from libplplot and put that
into a dll.  The upside of that for other front ends such as python is it
makes libplplot substantially smaller.  Also, I think reserving libplplot
strictly for plotting functions is just good organization that makes
everything much easier to maintain.  Splitting off the tcl/tk helper
functions would be a great step in the right direction, and I know Maurice
intends to split off the fortran stuff as well for similar organizational
reasons.

There is another less important issue.  It would probably be worthwhile to
keep the tkwin dll separate just to be in conformity with the way the rest
of the device dll's are treated.  So with these two changes (a) gets changed
to

(a') tcl dlopens tcl/tk helper function dll *and* tkwin dll under TEA

and (c) gets changed to

(c') the *tkwin* dll gets dlopened by plcore which would effectively be a
no-op.

Vince (or anybody else here), don't hesitate to comment on list about
refinements of this mental model of the way the linking happens if I was
unclear or got something wrong.  Of course our understanding of what goes on
in (b) and (c') and (d) doesn't really matter (so long as they work) because
those parts are all done automatically.

So the next question in my mind is how do you implement (a')?  In analogy
with the setup.py way of building the python interface dll, should the
tcl/tk helper function dll (and tkwin dll) be built under TEA control?  If
so, and given that I collect a list of tcl/tk helper C source files that
should be compiled and put into the tcl/tk helper dll rather than libplplot,
what is the cookbook?

Alan