Re: [Plplot-devel] xwin.c is now split

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

On Fri, 26 Jul 2002, [iso-8859-1] Jo=E3o Cardoso wrote:

> On Thursday 25 July 2002 21:37, Alan W. Irwin wrote:
> |  If everybody is happy with this splitting, the next step is to do
> | exactly the same to tkwin.c.
>
> I agree with the splitting of the xwin into another auxiliary driver to
> be used by xwin_drv and tk_drv. That is the obvious solution, other
> than just replicate the needed code into tk_drv.
>
> But I disagree in putting the common parts in libpltcl.
>
> Let's see, the tk driver is a driver that uses infrastructures from the
> tcl/tk bindings and also happens to use the xwin driver.....

Joao, your argument is based on the assumption that the code in tk.c (the
strict definition of what is meant by the tk driver) happens to use the xwi=
n
driver, and that assumption is not correct at all!  Certainly, the tcl/tk
bindings (as opposed to the tk driver) used functions defined in the old
xwin driver, but even that is now no longer the case.

To clarify the actual situation, the old problem was that libplplot itself
contained the tcl/tk bindings (in particular plframe.c) that had symbols th=
at
were resolved by xwin.c.  If you look at the 3 symbols you found by your
ingenious bash line; plX_setBGFG, PLColor_from_XColor, and plD_open_xw; in
every case it was plframe.c (not tk.c!) that had calls to those 3 functions
defined in the old xwin.c, and this was the source of all the previous
linking trouble.  That linking trouble is now cured by splitting out
xwin_common.c.

Note my goal was *not* to redesign the tk driver.  Instead my goal was
something much simpler; to make sure that no library would depend on
functions defined in driver code.  The side benefit of this cross-dependenc=
y
elimination was that the tcl/tk *binding* would be better organized.  I hav=
e
now achieved these goals by removing xwin_common.c from xwin.c.  The point
is the functions defined in xwin_common.c are referred to *both* by the new
xwin.c and plframe.c.

So the simple solution that breaks the prior cross-dependency between the
plplot libraries and xwin is to put xwin_common.o and the plframe.o code
that refers to it in the same library.  I don't care what that library is
called, but it made sense to me to put everything else in there that was
concerned with the tcl/tk binding. Once I get the linking reorganized into
my new scheme that library (lets call it libpltcltk for now) will be linked
to both libplplot and libtclmatrix. Thus, loading libpltcltk from wish
should just work. The load command under wish dlopens libpltcltk and becaus=
e
of the way that library will be linked in the new scheme, that dlopen shoul=
d
drag in libplplot and libtclmatrix as well. That wish situation is exactly
parallel to what happens in the python case so my simple goal of making sur=
e
no library code called functions defined in driver code and the soon to be
implement change to the new linking scheme should satisfy concerns we have
both expressed before about the way the tcl/tk bindings were organized.

Dropping the topic of the tcl/tk binding and moving back to the tk driver
topic, in the proposed new linking scheme, the tk driver simply links to
libplplot and libpltcltk just like the xwin driver, *but completely
independent of that driver* contrary to what you seemed to say above. Under
that scenario when the libplplot dynamic driver code dlopens the tk driver,
libplplot will already be loaded, libpltcltk will be automatically loaded
because of the way that the tk driver was linked, and beyond that
libtclmatrix will be automatically loaded because of the way that libpltclt=
k
was linked.  I think this is a very nice way to do things in Linux.  Lookin=
g
beyond that if we keep this basic organization for libtool and its dlopen
handler, we can get the same functionality cross-platform.

If there are no further objections I would like to split tkwin.c and move t=
o
the new linking scenario (which is not that different from the present chai=
n
linking scenario) early tomorrow and then give you guys the weekend (when I
will be largely out of e-mail contact) to hammer it to make sure it all
works for your various Linux distributions.

Alan