Re: [Plplot-devel] testing PLplot in-place

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

On Sunday 22 December 2002 08:46, Maurice LeBrun wrote:
> Wow, I finally caught up on all the email generated on the plplot lists=
=2E
> Now time to get down to work..
>
> One comment, about the ongoing discussion about being able to test the
> package "in place", i.e. w/o having to do a make install.  I changed th=
e
> subject heading to be actually relevant. :)
>
> Certainly it is very nice to be able to test the package before install=
ing
> it.  Many packages allow you to do this, but then in many ways they are
> simpler that what we are trying to accomplish.  I would be willing to g=
o
> to substantial lengths to support in-place testing, but if it is actual=
ly
> a Herculean effort.. then no.

We could first discuss the possible approaches and then evaluate the effo=
rt.=20
If no reasonable approach is possible, which I doubt, or if the effort is=
=20
Herculean, then agree to not do it.

What I propose is:
1-to have a "libs" directory (not ".libs", which are scattered among seve=
ral=20
directories)  where all libs will go when a plain "make" is executed;=20
executables will be linked at make time with those libs using rpath. At "=
make=20
install" time, executables and libraries will be relinked to the final=20
destination.

2-The dynamic drivers have to be searched for in at least two places: in =
the=20
build tree first and in the install tree latter; some form of relative=20
addressing should be used in order to avoid that an installed application=
=20
will use the build tree drivers.

3-Other files, such as fonts and maps also have to be searched in differe=
nt=20
places. Other front-ends will have to search for support files in two=20
different places -- this needs to be enumerated before going any further.

4-Plplot uses to have many search paths among the several front-ends, and=
 this=20
effort could be used to clarify them all. Relative addressing could be us=
ed=20
for them all (hmm...)? The library, at init time, could store the locatio=
n=20
where it is (how?), and from that point use relative addressing? This wou=
ld=20
solve point 2 above, as relative addresses are different in the build and=
=20
install tree. But I have not really though about this in detail.

But I don't think that we should worry about this now, as the release dat=
e is=20
approaching and our efforts should be directed to it, as the next to come=
=20
release will probably be in 2004 :-).

>
> At DejaNews I made the call that the developer had to run "make install=
"
> and test out of the install area before the whole thing would work.=20
> Developers would create one or more "play areas" that they'd install th=
e
> code to in order to give it a full workout.  Sometimes you have to choo=
se
> between an clear/elegant build + filesystem layout of the source code a=
nd
> being able to run it in place.  Although the latter is really nice to h=
ave,
> I'll sacrifice it if necessary in order to achieve the former.

I believe that a reasonable compromise is possible, and having the time (=
we=20
don't have deadlines here), we can accomplish it.
My personal problem is that I don't have=20
autoconf/automake/libtool/autotest/autoprogram/autorun/autodestroy (my si=
ck=20
humour ;-) experience. I never needed them for my own work, where a coupl=
e of=20
directories and Makefiles are enough, and I don't anticipate that I will =
ever=20
need, thus I'm reluctant to learn them all.


Joao