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

[Vince D. <vi...@sa...>]

I agree with all the below, except that 'TEA' is misleading.  All TEA is
is a collection fof stuff: a suggested way of building, installing, a
suggested directory structure, code conventions, etc.  None of it is
necessary.

Now that we have built a shared library with all of this, and it works, we
are "done".  Obviously there is cleanup that can happen, but TEA isn't
going to give us anything else (Ok: this isn't quite true, I mentioned
that we should ultimately compile with USE_TCL_STUBS and USE_TK_STUBS so
that we don't care what version of Tcl/Tk we load into, but again that can
wait).

So: to do what you want, you just need to build two separate dlls.  As you
say, there should be a base plplot dll and a separate tk-plplot shared
library with all the tcl-tk related stuff (in the future we might want
several of these, but lets ignore that for the moment).

On Fri, 12 Jul 2002, Alan W. Irwin wrote:
> (a) You would need some tcl/tk mechanism to dlopen that combined dll.  I
> assume that would be where TEA came in.

That will happen automatically.  No tea.

> (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).

Exactly the same for Tcl.

> (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.

Yup.

> 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.

Yes!

> 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

I don't see the need to complicate things this much, but feel free ;-)

> 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?

You don't need any helper functions at all.  Just build a shared library
and off you go.

cheers,

Vince.