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

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

On Monday 09 December 2002 17:11, Alan W. Irwin wrote:
| 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.

To make things clear: I just want to avoid the need to do a "make=20
install".

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

You are right here. But I think this should be discussed in another=20
thread, to no mix thinks like libraries and apps data. We control where=20
the data is.

| So I have a
| preference for adding a configuration option and using absolute
| directory addresses, but I could also live with no 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 be no problem there.

The problem is not how to generate libraries, but how/where will the=20
mother app (tcl or python) find them.
Anyhow, if you say that you will be able to run the tcl and python=20
examples *without* a "make install", then I will be happy. But in the=20
original post you said:

    "The python examples assume an installed location for the
     wrapper library, and the tcl and tk examples are even more
     dependent on installed data."

Again, I think that there is no problem for now if only data needs to be=20
installed. With "data" I *don't* mean the drivers. And yes, now I see,=20
the drivers are a good example to discuss this issue, because the=20
drivers are a kind of "extension modules" of plplot.

How do you intend to load the drivers without a "make install"? In the=20
installed directory, you can find a driver,
    /usr/local/test/lib/plplot5.1.0/drivers/xwin_drv.so

but in the build directory you only found=20
   drivers/xwin_drv.la
   drivers/xwin_drv_la-xwin.lo
   drivers/xwin_drv_la-xwin.o -> xwin_drv_la-xwin.lo

the real driver is in=20
   drivers/.libs/xwin_drv.la@
   drivers/.libs/xwin_drv.so*
   drivers/.libs/xwin_drv.lai
   drivers/.libs/xwin_drv.soT*

When the plplot library wants to load a driver, what will it look for?=20
xwin_drv.so, right? Or is that changed? That object can only be found at=20
the installed directoy or hidden in drivers/.libs.

Probably you will tell me that the plplot library is using libtool=20
dlopen, and that it will find the xwin_drv.so using xwin_drv.la. OK, it=20
works for our compiled examples, but *not* for pre-compiled apps.
Or I'm missing something?

Joao