|
From: Ole S. <deb...@li...> - 2018-11-23 07:28:54
|
Hi Alan,
"Alan W. Irwin" <Ala...@gm...> writes:
> On 2018-11-22 20:54+0100 Ole Streicher wrote:
>> "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....
It is the cmake command. When I start with an empty dir, and then do
$ cmake /usr/share/doc/plplot-doc/examples/
I get the following output:
--------------------------------8<----------------------------------------
-- The C compiler identification is GNU 8.2.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- CMake version = 3.12.3
-- CMAKE_SYSTEM_NAME = Linux
-- CMAKE_PLATFORM_INFO_DIR = /home/ole/Projects/2011/debian/plplot/x/CMakeFiles/3.12.3
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29")
-- Looking for pkg-config - found
-- cxx_compiler_library_pathname_list =
-- A test cmake run with language = Ada enabled failed.
-- Specify -DENABLE_compiler_diagnostics=ON to see full CMake diagnostics concerning this failure.
-- WARNING: no working Ada compiler so disabling ada examples.
-- The CXX compiler identification is GNU 8.2.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- The Fortran compiler identification is GNU 8.2.0
-- Check for working Fortran compiler: /usr/bin/gfortran
-- Check for working Fortran compiler: /usr/bin/gfortran -- works
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Checking whether /usr/bin/gfortran supports Fortran 90
-- Checking whether /usr/bin/gfortran supports Fortran 90 -- yes
-- Found JNI: /usr/lib/jvm/default-java/lib/libjawt.so
-- Could NOT find Qt5Svg (missing: Qt5Svg_DIR)
CMake Warning at /usr/lib/x86_64-linux-gnu/cmake/plplot/plplotConfig.cmake:5 (find_package):
Found package configuration file:
/usr/lib/x86_64-linux-gnu/cmake/Qt5/Qt5Config.cmake
but it set Qt5_FOUND to FALSE so package "Qt5" is considered to be NOT
FOUND. Reason given by package:
Failed to find Qt5 component "Svg" config file at
"/usr/lib/x86_64-linux-gnu/cmake/Qt5Svg/Qt5SvgConfig.cmake"
Call Stack (most recent call first):
CMakeLists.txt:471 (find_package)
-- CORE_Qt5_FOUND = ON
-- CORE_Qt5_VERSION_MAJOR = 5
-- CORE_Qt5_VERSION_MINOR = 11
-- CORE_Qt5_VERSION_PATCH = 2
-- Qt5_FOUND = 0
-- Qt5_VERSION_MAJOR = 5
-- Qt5_VERSION_MINOR = 11
-- Qt5_VERSION_PATCH = 2
-- WARNING: Qt5 core build-tree and install-tree inconsistency
CMake Error at /usr/lib/x86_64-linux-gnu/cmake/plplot/export_plplot.cmake:279 (message):
The imported target "_Pltk_init2.7" references the file
"/usr/lib/python2.7/dist-packages/_Pltk_init.so"
but this file does not exist. Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
"/usr/lib/x86_64-linux-gnu/cmake/plplot/export_plplot.cmake"
but not all the files it references.
Call Stack (most recent call first):
/usr/lib/x86_64-linux-gnu/cmake/plplot/plplotConfig.cmake:20 (include)
CMakeLists.txt:471 (find_package)
-- Configuring incomplete, errors occurred!
--------------------------------8<----------------------------------------
A Makefile is not produced then. The produced logfile is attached.
Any idea?
Best
Ole
|