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

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

On Tuesday 17 December 2002 19:54, Alan W. Irwin wrote:
> 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 n=
ow
> > | 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 woul=
d
> > solve it last.
> >
> > 2-finding libraries: libraries will be found by executables, thanks t=
o 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/.lib.

But I would expect AT to make that. It's hard to belive that developpers =
have=20
to rely on a hidden directory files... and as you are our AT expert...

> > 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 bui=
ld
> location of the extension.  For octave, I believe you use the -p parame=
ter
> 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 i=
s an
> additional issue of finding the tcl startup scripts in the build locati=
on
> rather than the install location.
>
> An additional issue is the rpath location of libplplot that all extensi=
ons
> must link to.

This is my issue.

> 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 oct=
ave
> plplot extension because currently that particular extension is not bui=
lt
> by libtool.

Ah, you mean that if octave modules extension was .so instead of .oct tha=
n the=20
problem would be solved? I could try to use and establish a link.

>  However, privately we discussed how you could build it with
> libtool, and I believe that would completely solve this issue.

Yes, but I didn't gave you the final anwser: mkoctfile is really build fr=
om=20
mkoctfile.in at configure time, after configure and libtool detects the=20
systems peculiarities. Also, mkoctfile if for ordinary users to use, not=20
necessarily to developpers, and all details are thus hidden. So mkoctfile=
=20
enables to build octave modules in all unix systems, win2000, djgpp, win9=
8,=20
macOS, etc. That's why I want to use it -- whatever the system is, using=20
mkoctfile guarantees that a module will be correctly built and linked.
To use it, it must be compiled twice, once for the build tree and again f=
or=20
the install tree. This could be simplified, I think, and only relink, not=
=20
recompile.

> 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 tim=
es
> in the past I got burned by this issue.  Thus, I strongly suggest we ha=
ve 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=
=2E

No problem.

> > 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/shar=
e/
> > /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>" wi=
ll
> > be enough.
>
> These complicated directions are *only* required if you are using "make
> check".

How the hell can I test the library, drivers, bindings, and examples? I m=
ust=20
do a "make check"!

By the way, "make check" is generally used to auto-check, where besides b=
eing=20
compiled, the tests are run and its output compared with know good result=
s.=20
In our case the target should be called "make demos". And to avoid the ne=
ed=20
to make all demos, we should have several targets, make cdemos, fdemos,=20
cxxdemos, alldemos, etc.

>  For now to avoid these complications I would advise avoiding "make
> check". Instead, I suggest sticking strictly with using installed resul=
ts
> (i.e., the current development cycle should consist of a programme chan=
ge,
> rm -rf <prefix>, make install, do test in the installed area).

But this is exactly what I'm saying: I'm not satisfied with the current A=
M=20
scheme!

> By the way,
> we are only talking an additional 20 seconds here (at least on my 600MH=
z
> machine) to do "make install", and it is substantially less if you limi=
t
> the configuration to just the features and driver(s) you are testing.

You are talking as a sales man, selling the lower figures :-).

In a real situation, where normally  I have the plplot tree configured fo=
r all=20
drivers and bindings, if I ocasionaly detect something that needs a chang=
e, I=20
must wait much longer than that. Only on very specific ocasions I have a=20
minimum set of drivers/bindings configured.

> > Thus, while I agree that AT is a good thing, there is still work to d=
o
> > to make our developper life confortable.
>
> Although only an additional 20 seconds in the test cycle is involved fo=
r
> developers, such latency is often annoying.  Thus, if you would like to
> work

If *we* agree that it is annoying, than *we* should work... sorry, you st=
arted=20
it...

And I like to reach a consensus of what to do and how before going forwar=
d.=20
When the decisions affects others. I dont ask when I correct a bug or=20
introduce a feature, that makes no sense; but on global issues, I like to=
=20
agree on what to do. This is also the reason why I'm not changing things.=
 (=20
and the total unknowledge on AT, which I would like to keep :()

But I don't want an ad hoc solution such as searching in the .libs=20
directories. Only if it is necessary, and its hard to believe that  AT, w=
hich=20
where made to easy developpers life will end up complicating it.

Anyhow, I don't have the time right now. And at the begining of the next =
year=20
I have to make ready a new discipline course. So it looks that AM will st=
ay=20
as is now.

> 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 vi=
ew
> this effort as release critical since it doesn't affect our users,

It will be if they want to test before install. You have to tell them=20
"configure with a test prefix, make, make install. If you like, than=20
configure again with the righ prefix, then make clean, make and make inst=
all=20
again."  I have already used this argument. Not critical, but annoying.=20
Nonetheless this issue I agree with a release at this (near) time.

> 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 availab=
le
> for plplot-5.1.0.  So if you are aware of user-related issues that you
> could fix or improve before the release, I hope you will give them high=
er
> priority than the removal of this developer cycle latency.
>
> Also, please don't freeze PLplot improvements at this time in anticipat=
ion
> of a release. Christmas is fast approaching so I have now resigned myse=
lf
> to some time in January as the earliest possible release date, and it c=
ould
> be indefinitely later than that because nobody at this time has stepped
> forward and taken responsibility for the -dev tk issue or the solaris w=
ith
> 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
> __________________________
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel