Menu
▾
▴
plplot-devel
|
From: Alan W. I. <ir...@be...> - 2002-12-09 06:06:11
|
I am quoting Joao in full below because apparently he cannot reach the list yet. I have some comments at the end of my own. Alan email: ir...@be... phone: 250-727-2902 FAX: 250-721-7715 snail-mail: Dr. Alan W. Irwin Department of Physics and Astronomy, University of Victoria, P.O. Box 3055, Victoria, British Columbia, Canada, V8W 3P6 __________________________ Linux-powered astrophysics __________________________ On Sun, 8 Dec 2002, Joao Cardoso wrote: > On Friday 06 December 2002 18:22, Alan W. Irwin wrote: > > make check now builds all non-installed examples fine, but the current > > situation is you will need some data installed to actually use the > > examples. Fonts and drivers are the only things requiring installation for > > the c, c++, and f77 examples. (I checked this by removing the installed > > libraries, but nothing else). > > Yes, I checked it too. Fixing this will be easy, but I have some reservations > on this. > > As an user, not developper, I often download/configure/make some packages, > just to evaluate them. Often I just "rm -rf the thing", after evaluating it > without installing. Till now very few packages couldn't be evaluated without > installing. This will not be possible with plplot, at least with the > interpreted bindings like python, tcl, octave and probably java. > > As a plplot user, I would download/configure/make the release to see if it is > worth installing it. Only after evaluation. This will not be possible > anymore. > > As a developper, I dont find practical the new scheme, at least for > interpreted languages. > > 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. Comments? Alan |
|
From: <jc...@fe...> - 2002-12-09 14:30:36
|
Ignore, please Joao |
|
From: <jc...@fe...> - 2002-12-09 15:15:21
|
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 |
|
From: Alan W. I. <ir...@be...> - 2002-12-09 17:13:05
|
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
|
|
From: Alan W. I. <ir...@be...> - 2002-12-09 18:22:01
|
On Mon, 9 Dec 2002, Alan W. Irwin wrote: > 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. OOPS. I subsequently learned that that ball is now in my court with Joao's useful demonstation of the problem in C, but it is still one thing at a time. Alan |
|
From: <jc...@fe...> - 2002-12-09 18:48:16
|
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
|
|
From: Alan W. I. <ir...@be...> - 2002-12-09 19:34:06
|
On Mon, 9 Dec 2002, [iso-8859-1] Jo=E3o Cardoso wrote:
> To make things clear: I just want to avoid the need to do a "make
> install".
> [...]The problem is not how to generate libraries, but how/where will the
> mother app (tcl or python) find them.
> Anyhow, if you say that you will be able to run the tcl and python
> examples *without* a "make install", then I will be happy. But in the
> 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
> installed. With "data" I *don't* mean the drivers. And yes, now I see,
> the drivers are a good example to discuss this issue, because the
> drivers are a kind of "extension modules" of plplot.
>
> How do you intend to load the drivers without a "make install"? In the
> 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
> 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
> 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?
> xwin_drv.so, right? Or is that changed? That object can only be found at
> the installed directoy or hidden in drivers/.libs.
> [...]
We have complete control of where to find the drivers. Look in plcore.c
at
sprintf( drvspec, "%s/%s/%s",
=09 DATA_DIR, "../drivers", driver->drvnam );
Another stanza would have to be put in there to look in an alternative
location. Also look elsewhere in src/*.c for DATA_DIR to find out
all locations that are affected.
I am not so familiar with the tcl part, but I believe in that case the
plplot initialization scripts define where the dynloaded shared objects are
so it is those scripts that would have to be modified if you want this no
"make install" capability. Similar remarks pertain to the location
of the plplot tcl initialization scripts as well.
For python, the location of the plplotc module is in
examples/python/plplot_python_start.py(.in). So we have complete control o=
f
specifying the module location in that case as well.
So to sum this up, with some work this should all be doable, but there are =
a
a fair number of places in the code and scripts that are affected so I woul=
d
still like to put this (the "no make install" option for lack of a better
description) under firm control of a configuration option.
Alan
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X