Alan W. Irwin writes:
> On Thu, 7 Nov 2002, Geoffrey Furnish wrote:
> > I know people are real hip on splitting all the language bindings out
> > of libplplot proper, but those language bindings are there because
> > applications use them. So if we're going to go this route, then
> > plplot-config needs to keep pace, and I guess, grow options so it can
> > spit out all the binding-specific drivel that has to be done just
> > right.
> I have already answered you privately, but I made mistakes in my response so
> please forget it.
> First, I just checked and plplot-config has been kept up to date with the
> linking simplification that occurred in July, and I don't think much has
> changed since.
> Secondly, I cannot confirm your problem with plplot-config.
Hmm. I've blown away that config by now, so I can't check without
redoing it all, but I'm thinking now that it is possible that I may
have used the wrong plplot-config. I thought I was doing it right at
the time, but maybe I biffed this part of it. So, don't sweat that
unless I write back to confirm.
> Would you please confirm that you can build the installed examples on your
> system with the latest PLplot cvs and tcl-8.3?
Not today, but I'll do this exercise again and let you know.
> If that is the case, then the obvious next question is what are you doing
> differently for your own toolchain so that plplot-config does not work for
> that specific case? One possibility is your toolchain may *directly* refer
> to tcl/tk symbols. If that is the case then you have to link those
> libraries in, independently of plplot-config. I am sorry if that is the
> case. However, remember the function of plplot-config is to link in the
> libplplot library.
Right. My app does do that, but I wasn't blaming plplot-config for
not (any longer) including -ltk and all that. I completely agree,
plplot-config --libs is only there to tell you how to link PLplot, so
the behavior you describe is correct.
> It does that job well, and that is all most applications
> (e.g., plrender, x??c) need. Recall that with the current linking scheme,
> linking to the tcl/tk libraries is necessary only for the drivers that
> explicitly reference tcl/tk symbols (e.g., tkd_drv.so) and for the
> libplplottcltk library. The present scheme does that linking automatically
> when you you build those drivers or the libplplottcltk library. Even pltcl
> and plserver don't refer to tcl/tk symbols directly so their linking only
> involves the libplplottcltk library.
> Another possibility is your toolchain refers to symbols in libplplottcltk.
Yes, that's me. By building a PLplot-enhanced Tcl shell, I am
effectively a glorified pltcl or plserver. So my app calls
Pltcl_init, Pltk_init, etc.
> Currently, we don't have an option for that case in plplot-config because it
> is not needed in the install, but we should develop such an option as a
> convenience for our users. Volunteers?
Anyone building a PLplot-enhanced Tcl shell, will need this. I think
this is what triggered my first email on this point, although I'll
still try to run the experiment again at some point, and confirm.
I think my app does not specifically have to do the Pltcl/Pltk tie-in
during AppInit. I don't have other init-time compiled code that needs
plframe. So, if we had it so that "package require Pltk" was
serviceable, then maybe I wouldn't have to mimick pltcl's startup
I haven't looked at this for a while. My recollection was that pltcl
was pretty sophisticated, and it paid to mimick it carefully. I'm not
sure we can really recover exactly what we need, using only a package
based approach. I hope so, but I would regard that as somewhat
innovative, starting from where I think we are. But maybe my memory
on this paints the beast larger than life. I'll have to go back and
look at this, at some point.
Anyway, my point is this. For sure, apps need to be able to get
plframe registered in their own custom Tcl_Interp *. The way I have
always done this, is to call Pltcl_init/Pltk_init, which requires
plplot-config --libs to tell all that is required for that to work.
That requirement could maybe be dropped, if there was a Tcl-level way
to get plframe installed in the interpreter. That's the TEA branch
stuff. I know its worked for Vince in that context, but I don't think
we have this full capability on cvs head yet, do we?
Geoffrey Furnish furnish@...