Re: [Plplot-devel] New java configuration completed and tested and other configuration news

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

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

> On Tuesday 17 December 2002 05:51, Alan W. Irwin wrote:
> ...
> | All drivers (configured both dynamically and statically) are also now
> | configured with the new scheme. So there should be no further major
> | additions to the current configuration scheme
>
> I don't quite agree. If your AT effort does simplify our (developper)
> job, by automatically providing plplot on (potentially) new platforms,
> it does turns the development cycle longer and tedious, because the
> need to "make install".
>
> The problem is how to develop in the build tree without the need to
> install. There are three situations:
>
> 1-finding data like fonts, etc. This should be pretty easy, so I would
> solve it last.
>
> 2-finding libraries: libraries will be found by executables, thanks to a
> wrapper with the same name of the executable that points to the .libs
> hidden libraries. This point is also solved, but we must be sure that
> the build tree library is searched first than an installed library by
> the executable wrappers.
>
> 3-finding drivers: this currently does not work. drivers must be
> installed, and this means "make && make install" after each
> modification to a driver. As "make install" also installs other files,
> this might add difficulties to a debugging cycle, see bellow.

This should be as simple as finding the build (as opposed to installed)
fonts, maps, etc.  The drivers.db file is generated (by configure) in
plplot/drivers, and all the xxx_drv.so files are built in plplot/drivers/.l=
ib.

>
> 4-interpreted languages that dlopen they own plplot extensions.
> Currently Octave only works with plplot installed. I don't know if
> other languages has the same problem.

One issue is that for every scripting language you have to tell it the
location of the extension.  But we know exactly where all of these
extensions are built so it is a straightforward problem to solve.  For
example, in the python case the installed extensions are found in the
following way for my configured setup:

(This is the totality of plplot/examples/plplot_python_start.py).
# Append to effective python path so that can find plplot modules.
import sys
sys.path.insert (0, "/usr/local/plplot_at/lib/python2.1/site-packages")

So it is a matter of changing this file if you want to refer to the build
location of the extension.  For octave, I believe you use the -p parameter
on the octave command to specify the location of the extension. The
automatic searching for extensions by tcl is still an art rather than a
science so that will be the most problematic one.  BTW, for tcl there is an
additional issue of finding the tcl startup scripts in the build location
rather than the install location.

An additional issue is the rpath location of libplplot that all extensions
must link to. That is automatically taken care of for all extensions that
are built by libtool; at build time the build location of libplplot is used
and at install time everything is automatically relinked to use the
installed location of libplplot.  The only exception to this is the octave
plplot extension because currently that particular extension is not built b=
y
libtool.  However, privately we discussed how you could build it with
libtool, and I believe that would completely solve this issue.

A final issue with getting things to work both in the build and install
areas is confusion over which you are using.  I don't know how many times i=
n
the past I got burned by this issue.  Thus, I strongly suggest we have a
configuration option which allows us to make the choice between either the
build area or installed area with no possible confusion between the two.

> but to avoid misunderstandings,
> please "rm -rf <prefix>" before reporting a working binding: in my
> case, I do "make && make install &&  rm -rf /usr/local/test/bin
> /usr/local/test/include/ /usr/local/test/python/ /usr/local/test/share/
> /usr/local/test/lib/lib* /usr/local/test/lib/plplot5.1.0/tcl". When
> point 1 and 3 above becomes solved, than a plain "rm -rf <prefix>" will
> be enough.

These complicated directions are *only* required if you are using "make
check".  For now to avoid these complications I would advise avoiding "make
check". Instead, I suggest sticking strictly with using installed results
(i.e., the current development cycle should consist of a programme change,
rm -rf <prefix>, make install, do test in the installed area). By the way,
we are only talking an additional 20 seconds here (at least on my 600MHz
machine) to do "make install", and it is substantially less if you limit th=
e
configuration to just the features and driver(s) you are testing.

>
> Thus, while I agree that AT is a good thing, there is still work to do
> to make our developper life confortable.

Although only an additional 20 seconds in the test cycle is involved for
developers, such latency is often annoying.  Thus, if you would like to wor=
k
on issues 1-4 and the additional issues with using the build area for tests
that I have discussed, then please go ahead.  However, I don't view this
effort as release critical since it doesn't affect our users, and it is
becoming critical to make the release so our users can enjoy all the bug
fixes and new features already on CVS HEAD compared to what was available
for plplot-5.1.0.  So if you are aware of user-related issues that you coul=
d
fix or improve before the release, I hope you will give them higher priorit=
y
than the removal of this developer cycle latency.

Also, please don't freeze PLplot improvements at this time in anticipation
of a release. Christmas is fast approaching so I have now resigned myself t=
o
some time in January as the earliest possible release date, and it could be
indefinitely later than that because nobody at this time has stepped forwar=
d
and taken responsibility for the -dev tk issue or the solaris with tcl/tk
test that are currently holding up the release.

Alan

email: ir...@be...
phone: 250-727-2902=09FAX: 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
__________________________