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

[<jc...@fe...>]

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

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

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

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

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

I agree.

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

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

Joao

|
|  Alan
|
|
|
|
|  -------------------------------------------------------
|  This sf.net email is sponsored by:ThinkGeek
|  Welcome to geek heaven.
|  http://thinkgeek.com/sf
|  _______________________________________________
|  Plplot-devel mailing list
|  Plp...@li...
|  https://lists.sourceforge.net/lists/listinfo/plplot-devel