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

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

On Monday 09 December 2002 06:04, Alan W. Irwin wrote:

=2E..

| > 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=20
quite agree. While your proposal makes sense, I think that we could=20
search in both locations, in the build tree and in the install tree, as=20
long as we search first in the build tree and after that in the install=20
tree. As long as we use relative adresses when searching in the build=20
tree, there is no risk that an user app will end up using a build tree=20
file.
This will simplify both the code and the configuration.

But that was not what I want to discuss.

While apps. that use libraries can be fooled by libtool wrap scripts,=20
that search for libs in the libtools .libs directories and in the=20
install lib directory (that's why the c examples run OK even if the=20
install tree libraries don't exist), the same does not happens for=20
apps. that dlload modules (pluggins, as you call it in another mail).

For example, Octave loads plplot_octave.oct, but knows nothing about=20
plplot; the location of the libraries used by plplot_octave.oct must be=20
coded in plplot_octave.oct itself. plplot_octave.oct can't be a libtool=20
wrapper script, as Octave expects to find a "module". I am pretty sure=20
that the same happens with python, tcl, perl and java.
In the old configuration scheme, plplot_octave was compiled twice, once=20
(a plain "make") specifying where libplplot.so was in the build tree,=20
and the other where libplplot.so was in the install tree (a "make=20
install").
I propose something similar now: a plain "make" would link apps against=20
the libraries located in the build tree; a "make install" would compile=20
(link) apps. against libraries in the install tree. i.e., I would turn=20
the current "make" into "make install", and create a new "make".

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

Joao

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

Joao

|
| Comments?
|
| Alan