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" <alan.w.irwin1...@gmail.com> 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
__________________________


_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to