Re: [Plplot-devel] Help needed for plplot runtime tests

[Alan W. I. <Ala...@gm...>]

On 2018-11-22 20:54+0100 Ole Streicher wrote:

> Hi Alan,
>
> back from the US (ADASS), I found an hour to look further into the CI
> tests problem:
>
> "Alan W. Irwin" <Ala...@gm...> writes:
>> On 2018-11-13 18:23+0100 Ole Streicher wrote:
>> Upstream PLplot installs all examples configured in the core build in
>> one place which contains a self-contained CMake-based build and test
>> system for those examples.  Therefore, I have to agree splitting up
>> those installed examples in various locations is not a good idea
>> since that means you have to implement a build system for each
>> component of the examples!
>>
>> Therefore, I suggest instead you create a plplot-examples
>> package that contains only text files, which are *all* the example files
>> that upstream currently installs in
>> $PREFIX/share/plplot$VERSION/examples, but it sounds like instead
>> for debian if you do this suggested reorganization
>> you should install them in /usr/share/doc/plplot-examples/examples.
>
> OK, so I now moved all examples to the "examples" subdir of the
> plplot-doc package, and now I am closer to a working test ;-)
>
> Next problem is that the Debian installation script renames the shared
> libraries that are installed for the Python package:
> On Python 2.7,
> - _Pltk_init.so becomes _Pltk_init.x86_64-linux-gnu.so resp.
> - _plplotc.so becomes _plplotc.x86_64-linux-gnu.so
> On Python 3.6
> - /usr/lib/python3.6/dist-packages/_Pltk_init.so becomes
>   /usr/lib/python3/dist-packages/_Pltk_init.cpython-36m-x86_64-linux-gnu.so
> - _plplotc.so similar
> And Python 3.7 similar.

Hi Ole:

I am glad to hear you are making significant progress.

I looked deeper at the names of the python *.so files for Debian Buster for one arbitrary python package (curses).

irwin@merlin> find /usr/lib/python3.7/ -type f |grep 'curses' |grep -E '(.py|.so)$'
/usr/lib/python3.7/curses/panel.py
/usr/lib/python3.7/curses/__init__.py
/usr/lib/python3.7/curses/has_key.py
/usr/lib/python3.7/curses/textpad.py
/usr/lib/python3.7/curses/ascii.py
/usr/lib/python3.7/lib-dynload/_curses.cpython-37m-x86_64-linux-gnu.so
/usr/lib/python3.7/lib-dynload/_curses_panel.cpython-37m-x86_64-linux-gnu.so

And that relocation (to lib-dynload) and extra
".cpython-37m-x86_64-linux-gnu" description in the *.so file names
made no difference to the *.py files.  For example, panel.py had the
following import statement

from _curses_panel import *

with no mention of the location or extra name decoration of the corresponding *.so file.

So from the results of that quick check, I don't understand why the installed PLplot example
tests are complaining
about the renaming (and even relocating to a different directory) of PLplot's installed
python *.so files).  Which leads to the following response to your question....

> Is there a way to switch off the consistency check for Python?

Please clear up exactly what you mean here by giving me the
VERBOSE=1 output of the test target that is failing.  For example,
if you are building the test_noninteractive target, you could
extract that necessary output this way.

make VERBOSE=1 test_noninteractive >& test_noninteractive.out

Given that output file, I could probably figure out a quick patch for you to
get by whatever the error is because (as I found out above for curses)
renaming and relocating *.so should not matter.

My guess is that likely the PLplot build system is being much too
specific about a name and/or location in the installed python files
for PLplot.  But assuming that is the case, I can find out where that
is done a lot easier once I have your VERBOSE=1 test target build
output in hand.

> BTW, I would still keep the dependencies of the -doc package as they
> are, and only for the tests install everything.

Well, if you haven't done this already, I would suggest putting all
the names of the relevant binary packages into the Suggests: list for
the -doc package.  (I assume that will be the final form you want once
I get the upstream code properly factored since once that is done
those binary packages will add substantially to the functionality of
the -doc package which I believe is what Suggests: is for.)

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________