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

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

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

> On Friday 26 July 2002 08:58, Alan W. Irwin wrote:
> |  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 xwin 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.
>
> No. It does not matter where the code that makes tk_drv is.

Sorry, Joao, but I cannot agree at all with that statement.  Where the code
is located (i.e., what file) is the primary consideration for whether the
linking works or not.

>
> The tk driver uses a plframe, wich is a tk plot widget built
> specifically for plplot. The plframe should be considered part of the
> tcl/tk bindings, as it is just one more tk widget. The plframe is
> created in plframe.c, and in plframe.c:plFrameCmd() the xwin driver is
> deliberatily opened:
>  /* Partially initialize X driver. */
>     plD_open_xw(plFramePtr->pls);
>
> Further, plframe.c says:
>     This module implements "plframe" widgets for the Tk toolkit.
>     These are frames that have extra logic to allow them to be
>      interfaced with the PLplot X driver.  These are then drawn into
>      and respond to keyboard and mouse events.
>
> To say it another way: the gnome driver uses a gnome plot widget that
> Rafael did not have to write it, as Maurice did with the tk plframe.
> The gnome driver links with gnome libraries, the tk driver has to link
> with the library where the plframe is and with tcl/tk libs.

And because of that design, plframe *must* link with xwin_common.o, i.e,
xwin_common.o is absolutely essential to plframe.

> I agree with the splitting, but I do not agree in
> puting xwin_common in libtcltk. It *is not* and *should not* be part
> of a tcl/tk library!
>
> And what happens if someone does not want/has tck/tk but still wants
> the xwin driver? Do we have to build a libtcltk with only
> xwin_common.o as the only object file? No, you can't convince me.

It doesn't bother me a bit to have one quite specific configuration where
xwin_common.o is the only thing that occurs in libtcltk.  If you feel reall=
y
strongly about this, perhaps you could rename xwin_common.o to
plframe_xwin_common.o?

>
> The right track is to put
>
>        if (!dlopen ("<path?>/xwin_common_drv.so", RTLD_LAZY))
>                       exit(1);
>
> in both xwin.c and tk.c at plD_init_xx, and to put xwin_commo_drv.so in
> the same directory as the other drivers.

tk.c does not require a single function in xwin_common_drv.so so why are
you suggesting it should dlopen it?

> |  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,
>
> Ah! the xwin driver links with libtcltk! doesn't that sounds strange to
> you?

Not a bit. But if you are really bothered by it, we can call it the
libtcltkxwin library.  I believe what is fundamentally bothering you is the
libpltcltk library as it now stands has several different uses.  We could
split that library again so that xwin_common.o is in its own library that i=
s
linked to both by libpltcltk and xwin, but at some point it is better to
have miscellaneous uses for a library rather than the overhead of too many
small libraries. It is a question of where you draw the line.  Remember,
xwin_common.c only has 500 lines of code spread amongst 7 small functions.
For now, I am going to leave it in libpltcltk, but if somebody feels
strongly enough to split it off into its own separate library, they can do
so later.

>
> | *but completely independent of that driver* contrary to what you
> | seemed to say above.
>
> I was not talking on linking requirements but on design considerations.

Exactly.  But we have to be practical.  Linking requirements are essential
for *any* design.

>
> | 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 libpltcltk was linked.
> | I think this is a very nice way to do things in Linux.  Looking
> | beyond that if we keep this basic organization for libtool and its
> | dlopen handler, we can get the same functionality cross-platform.
>
> And what about this? at plinit() the driver is ldopened() in
> plLoadDriver(), and at plD_init_tk() the driver
> dlopen("xwin_common.so",...)?

Again, it is plframe which needs xwin_common.o, *not* tk.  It's the content
of the files (plframe.c versus tk.c) that dictate whether the linking works
or not.

>
> Both libplplot and libtcltk where specified in the link command, and
> thus are available, and libtclmatrix was specified as a requirement
> when libtcltk was built, and as such will be loaded.
>
> |  If there are no further objections I would like to split tkwin.c
> | and move to the new linking scenario (which is not that different
> | from the present chain 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.
>
> It will work. But it is not a good design. As a matter of fact it was
> not designed, it just works.

I will happily settle for something that works rather than the linking mess
we had before that was keeping us from building dynamic versions of the tk,
xwin, and tkwin drivers.

Alan