Re: [Plplot-devel] "make check" support installed for c++, f77, and tk examples

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

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

> On Monday 09 December 2002 06:04, Alan W. Irwin wrote:
>
> ...
>
> | > Lets see, if I (user/developper) have to install after make and
> | > before use, in order to not disturb my system, I will install in
> | > /usr/local/test. After everything looks fine, I will have to
> | > configure/make/install again to install in the final place. Why
> | > doesnt we install in the current location from the start? If we
> | > like, we will configure/make/install to the final place, but
> | > meanwhile we could evaluate/improve/debug in-place -- without the
> | > mess of never exactly knowing if we are running the installed or
> | > the just built library, as it recently happened with you.
> | >
> | > Joao
> |
> | You should forget that e-mail from me.  It detailed what worked now
> | and why. But I don't think that is the ultimate solution if you want
> | to work more on this.
> |
> | Here is what I suggest.  Make a configuration option
> | (enable-original-data or whatever better name you can come up with)
> | that by default is disabled. However, when the user enables it, the
> | code searchs for everything (drivers, fonts, tcl scripts) in the
> | original location rather than the usual installed location. Our code
> | would have to be changed to pay attention to this option, whenever
> | searching for drivers, fonts, or tcl scripts, but at least with such
> | an overall option it would be either one clear location or the other.
> | The problem of searching both locations at once as in the old system
> | is the behaviour depends on whether there was an old install around
> | or not.  Most developers here have been caught by that problem with
> | the old system.  At least with a configuration option the user has
> | made a clear choice, and it is guaranteed (if you do the programming
> | changes properly) that *only* one location (either original or
> | installed but not both) will be searched.
>
> That is not the point that I want to discuss, but nevertheless I don't
> quite agree. While your proposal makes sense, I think that we could
> search in both locations, in the build tree and in the install tree, as
> long as we search first in the build tree and after that in the install
> tree. As long as we use relative adresses when searching in the build
> tree, there is no risk that an user app will end up using a build tree
> file.
> This will simplify both the code and the configuration.

I just want to be iron-clad guaranteed that we are getting the right data.
Your idea of relative directory addresses should work to give us (nearly)
this same guarantee, but the drawback is it means apps can only be executed
in one directory level (either plplot/examples or its many subdirectories,
but it could not be both.) So I have a preference for adding a configuratio=
n
option and using absolute directory addresses, but I could also live with n=
o
configuration option and the relative directory idea.  What do the other's
think?

>
> But that was not what I want to discuss.
>
> While apps. that use libraries can be fooled by libtool wrap scripts,
> that search for libs in the libtools .libs directories and in the
> install lib directory (that's why the c examples run OK even if the
> install tree libraries don't exist), the same does not happens for
> apps. that dlload modules (pluggins, as you call it in another mail).
>
> For example, Octave loads plplot_octave.oct, but knows nothing about
> plplot; the location of the libraries used by plplot_octave.oct must be
> coded in plplot_octave.oct itself. plplot_octave.oct can't be a libtool
> wrapper script, as Octave expects to find a "module". I am pretty sure
> that the same happens with python, tcl, perl and java.

No. the python and tcl libraries are generated by libtool so there should b=
e
no problem there.  Java is not done, but my plans are to generate that
library with libtool.  Same is true for perl (way down the road when perl i=
s
ready).  So the only odd one out is octave.  If it wasn't for their
strange suffix ".oct" I could do that with libtool as well (see below).

> To avoid using deep relative adresses, like ../../src/.libs, we could
> setup a lib directory in the build tree, and make symbolic links to the
> location of the real libraries.

I don't think that will be necessary since the octave library is the only
one with the problem at this point.  And if I can figure out a suffix issue
(see below), it won't be a problem for long.

>
> PS- the libtool info nodes adresses the issue of "dlopened modules", but
> it assumes that one has control over the app that will use the module,
> which is not the case, i.e., we don't have control how Octave loads
> plplot_octave.oct, nor how will python or perl load their plplot
> modules (language extensions, in the libtool parlance).

Let's concentrate on python and tcl since perl will only be relevant a long
time from now (unless somebody gets interested in it).  In both cases,
libtool builds the shared objects libplplottcltk.suffix and
plplotcmodule.suffix, where suffix ("so" on Linux) is appropriate to
whatever platform we are dealing with.  If you look at the tcl scripts ther=
e
is a mechanism there to load the plplot extension with a cross-platform way
to get the right suffix for the platform.  So that is an excellent match fo=
r
what libtool does.  I haven't looked at python in detail, but I assume thei=
r
import statement does something similar.  So that takes care of any naming
problems, and the internals are covered because libtool knows how to build
shared objects, which is all that is required for any language extension
including the python and tcl extensions.

Octave has taken a different approach.  Their mkoctfile script does all it
can to make a shared object in a cross-platform way.  Essentially, they are
trying to do libtool's job of building shared objects. However, they solved
the naming suffix problem by just using one, "oct".  Now I could do
everything mkoctfile does using libtool, but that suffix issue is the one
remaining problem. On Linux of course I could make a symlink between the
*.so result of libtool and *.oct, but I am still thinking about how to do
this in cross-platform way when that .so suffix could be anything.  I
believe the solution is to grep for dlname in the *.la file to find the
correct name to symlink to.

So I do have definite plans to make sure the octave shared object is built
with libtool just like the rest of our shared objects. But before I try any
more octave changes I would like you to fix up the test scripts so the "x"
examples work.  One thing at a time.

Alan