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 |