Re: [Plplot-devel] build broken

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

On Mon, 16 Sep 2002, [iso-8859-1] Jo=E3o Cardoso wrote:

> On Saturday 31 August 2002 13:24, Alan W. Irwin wrote:
> | [...]My solution for this
> | Gordian knot was the same as Alexander's.  I split everything up!
> | All the tcl and tk interface stuff is now split off from libplplot
> | into its own library libplplottcltk[d].
>
> This is a good thing.
> Can we make also a libplplotf77 library from scstubs.o sfstubs.o?

I hope so.  If I recall correctly, this has long been on Maurice's ToDo lis=
t.

Geoffrey, would you also be willing to go along with splitting out the java
interface stuff from libplplot if I do the work?  Ultimately, I would like
to see all interface API removed from libplplot. I think it just makes
maintenance issues a lot easier to solve if we move toward reserving
libplplot exclusively for fundamental PLplot API.  Ultimately, I guess it
just boils down to the Unix philosophy of splitting everything up into
small specialized entities which communicate well (in this case by the link=
ing
mechanism) rather than attempting an integrated approach.

> |  [...] A different solution
> | (suggested by Vince) for simplifying libplplottcltk was taken for the
> | tkwin case where everything associated with tkwin was put into the
> | tkwin dynamic library.  Thus, tkwind_drv.so now contains
> |
> | Plplotter_Init.o plplotter.o tkwin_common.o tkwin.o
>
> Good. Of course this implies that the user has to specify the location
> of tkwin_drv.so.
> It's easy to do in the build directory, but might cause problems in the
> installed location--the user must know where it is. From other e-mails
> I understand that the problem was already solved setting 'auto_path' by
> using 'lappend', I just dont know if this is performed automatically or
> if it requires the user to set it up.

I got everything to work well in the build location, but there are still
some Tcl/Tk install issues which I have now forgotten but which I documente=
d
to the list.  I suspect there is a simple solution, but it will need to be
provided by a Tcl Linux expert.

>
> That's fine. The only missing thing is to reunify tkwin_common.c and
> tkwin.c, I believe.

I don't care one way or the other here, and I believe the same is true
for Vince.  So if you want to reunite tkwin, please go ahead.

>
> [...] The other object files in libplplottcltk.* (but tclAPI.o) are
> application dependent, and should, I think, be linked directly with the
> applications they were written for, as they are useless for other
> programs or the user:  Pltk_Init.o is for the tk_win driver (and I
> checked that if removed from libplplottcltk.so and included in
> drivers/tkwin_drv.so the tkwin driver still works), tclMain.o is for
> pltcl, and tkMain.o is for plserver.
> With these changes, libplplottcltk.* would contain only tclAPI.o,
> plframe.o, tcpip.o and plr.o.
>
> These changes would only clarify what is from what, without any
> advantages or disadvantages.

Sounds good to me!  Unfortunately, it is taking me longer than I thought to
finish my current astronomical research project (partly because I have been
sneaking in a lot of work on short plplot projects) so it may be late
October *at the earliest* before I can get to this.  So if you could do it
first, I would much appreciate it.

Alan