On Saturday 27 July 2002 08:43, Alan W. Irwin wrote:
| 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.
tk_drv is also essencial, and is not linked. It is a driver.
| > 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 really strongly about this, perhaps you could rename
| xwin_common.o to plframe_xwin_common.o?
It is not a matter of name, but where things should be and how they=20
| > 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?
Come on! the tk driver needs the plframe, that needs the xwin driver!=20
And yes, I think that plframe.o should be part of the driver, and as=20
such linked with tk.o to make tk_drv. But the plframe only makes sense=20
with tclAPI, so should we link them all? No, if I configure with=20
--enable-tcl --disable-tk, than tclAPI.o will be built, plframe.o will=20
not, and I can use other driver then the tk_drv one.
| > | 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
Yes. I would say " several non-related uses". If you want to call it=20
libplmisc I would complain again. It is not the name, it is not the=20
linking, it is the fact that things can be done in another, cleaner=20
For example, tclMain.o is only used by pltcl -- why is it in the=20
library? why not link it only in the pltcl link command line? The same=20
for tkMain.o and pltk_Init.o, which are only used by plserver. The=20
same for plplotter_Init.o and plplotter.o, that are only used by=20
| We could split that library again so that xwin_common.o is in
| its own library that is 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
Things where OK when there was no dynamic drivers. All had to be put in=20
a single library. With dynamic drivers the core library is clean of=20
device dependent code. Bindings libraries (or loadable extensions) are=20
also free of device dependent code. Why should the tk driver be an=20
exception? Drivers should consist of a single source file, but=20
sometimes that is not practical, but that is not a reason to just=20
create another library. If it is a driver, or part of it, let it go to=20
the drivers directory. (my border line does not imply to put libplplot=20
in the drivers directory, as all drivers depend on it.)
Strictly speaking, the only source file that should go to libtcl is=20
tclAPI.o. plframe.o, tcpip.o and plr.o are support files for the=20
plframe, that is used by the tk driver.
Unfortunately the tk driver and the tcl bindings are all mixed=20
together, which makes my needs for regularity an impossible task.
| > | *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.
Again, it is the xwin drviver that needs xwin_common. That's for it=20
that is was written in the first place. The tk driver needs the xwin=20
driver. I'm talking of abstract things, not source files.
| > 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.
I consider this discussion closed for what concerns to me, and I will=20
not participate in it anymore. I do not however agree with the=20
And this was unfortunatelly a one-to-one man discussion, so I don't=20
know what others think. Thus this discussion is fruit-less.
| This sf.net email is sponsored by:ThinkGeek
| Welcome to geek heaven.
| Plplot-devel mailing list