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

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

On Wed, 18 Dec 2002, Joao Cardoso wrote:

> > An additional issue is the rpath location of libplplot that all extensions
> > 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 octave
> > plplot extension because currently that particular extension is not built
> > by libtool.
>
> [...] That's why I want to use it -- whatever the system is, using
> 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 for
> the install tree. This could be simplified, I think, and only relink, not
> recompile.

If you want to stick with mkoctfile that is okay with me, but then you have
to explicitly find the solution for linking a version at build time with a
build rpath and relinking at install time with a install rpath.  I am sure
there is a reasonably straightforward way to do this with the appropriate
automake syntax and time stamp files, but I haven't thought very much about
it since I was concentrating on a different solution.

> > 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 must
> do a "make check"!

This claim weakens your argument since make check is definitely not
necessary for testing. Instead do the following: cd to the install location
of the c examples, $prefix/lib/plplot5.1.0/examples/c. "make -f
Makefile.examples x01c". (I have mentioned this step before to the list, but
perhaps you failed to notice it?) Run x01c with the variety of drivers you
want to test.  This procedure tests the library, drivers, c binding, and
example. If you want to test other bindings then go to the appropriate
directory in the installed examples instead.  If you want to test all the
non-interactive examples simply run plplot-test.sh, but that is overkill and
running single examples usually does all the testing you need.

Have you ever tried testing this way in the installed location?  If you try
it you may find it is not that bad, and then the whole argument goes away.

>
> > 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
> > the configuration to just the features and driver(s) you are testing.
>
> You are talking as a sales man, selling the lower figures :-).

Nope.  I am not trying to sell this at all.  Instead, I am trying to give
you information about my real recent experiences with testing programme
changes with the new configuration scheme.  To expand this information I
decided to time all the steps accurately for you and the others so there is
no mistake about the relatively small amount of time we are discussing here.
Everything done after a rm -rf /usr/local/plplot_at/* and make distclean on
my AMD 600MHz machine.

(1) time ./bootstrap.sh >& bootstrap.out
18.640u 0.390s 0:20.35 93.5%    0+0k 0+0io 7383pf+0w

(2) time ./configure --prefix=/usr/local/plplot_at  \
--enable-dyndrivers --enable-octave --enable-java >& configure.out
17.270u 10.440s 0:32.67 84.8%   0+0k 0+0io 406819pf+0w

Note this configure includes every driver except for linuxvga (missing library
on my system) and gnome and ntk (turned off by default).  Also
tcl/tk, python, c++, f77, java, and octave.

(3) time make >& make.out
174.740u 17.870s 3:45.53 85.4%  0+0k 0+0io 556384pf+0w

(4) time make install >& make_install.out
14.640u 8.040s 0:26.71 84.9%    0+0k 0+0io 282441pf+0w

Before I got ~20 seconds (as I stated) rather than 27 seconds for this step,
but then I probably wasn't installing java and octave.

(5) touch src/plcore.c (emulate a change in plcore.c).

(6) rm -rf /usr/local/plplot_at/*

(7)  time make install >& make_install.out
19.830u 8.910s 0:32.35 88.8%    0+0k 0+0io 309732pf+0w

Steps 5-7 emulate a change in source code. As expected, the make install is
a bit longer than step 4 since plcore.c had to be compiled (I checked this
occurred).  But if you don't configure a lot of different components and
drivers, this ~30 second near worst case latency can be made substantially
smaller. Also note that autotools does very good dependency tracking so when
you change a file a minimum of recompilation and relinking is done for
the install.


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

See real numbers above for near worst case ~30 sec latency from make install
after a change.  If you do the same tests do you really get much slower
results on your 700MHz machine? Note neither machine is a front end machine
any more and in any case you can get substantially lower latency if you cut
down on unused drivers and front ends.  So my conclusion is not many
developers are going to be bothered that much by this latency.

>
> > > 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
> > work
>
> If *we* agree that it is annoying, than *we* should work... sorry, you started
> it...

I was trying to "lean over backwards" to understand your concerns.  However,
your argument forced me to look at the timing numbers again, and they
confirm this is not a high priority for my needs (or most other developer's
needs). However, since you obviously do feel this is a high priority, then I
have been willing to cooperate by laying out for you what you have to do in
a fair amount of detail which has taken a substantial amount of my time.
Much of it is C code change such as telling plcore.c where the drivers are
built (see below) or where the font and map data are located.

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

There is nothing magical or ad hoc about .libs.  That is the standard
subdirectory location in any particular directory where libtool puts its
results.  If that's where the drivers are built, then you have to tell
plcore.c to look in that location.  It is exactly analogous to the old days
where we had plcore look in plplot/tmp as well as the install locations.  It
really is as simple as that.

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
__________________________