Menu
▾
▴
plplot-devel
|
From: Ole S. <deb...@li...> - 2018-11-09 22:32:35
|
Hi,
in the Debian package, we usually try to run CI tests regularly on each
dependency change. This gives us the opportunity to early find problems
with the package or one of its dependencies.
However, I have some difficulties to do that; this may be connected with
my limited knowledge of cmake.
The test is started with the binaries installed in the system and the
sources unpacked. The working dir is the root of the sources.
What I basically do now is to run the following script:
--------------------8<---------------------
#!/bin/sh
set -e
SRC=$(pwd)
test_dir=$(mktemp -d)
cd $test_dir
cmake $SRC/examples
make test_diff_psc
make test_noninteractive
--------------------8<---------------------
However, the "cmake" step fails with
--------------------8<---------------------
[...]
-- CMAKE_SYSTEM_NAME = Linux
-- CMAKE_PLATFORM_INFO_DIR = /tmp/tmp.TwEFoteIXX/CMakeFiles/3.12.3
CMake Error at CMakeLists.txt:469 (include):
include could not find load file:
plplot_configure
--------------------8<---------------------
How could I fix this?
Best regards
Ole
|
|
From: Alan W. I. <Ala...@gm...> - 2018-11-24 18:55:11
|
Hi Orion: This thread has previously been directed mostly at Ole, but I am including you now because I think it will interest you. It concerns the problems (one of them upstream which I plan to fix soon by factoring the export files [as I promised you long ago, but it got lost on the stack until Ole ran into this problem again!]) that Ole has been having with Debian to get testing working properly for the installed examples. I would appreciate you contributing to this thread. For example, if all Fedora binary packages are installed (which works around the above factoring problem until I can get it fixed) do the following tests of the CMake-based and legacy-based installed examples work? # CMake-based build system for the installed examples # Move to initially empty build tree first. rm -rf /tmp/plplot_cmake_test mkdir /tmp/plplot_cmake_test cd /tmp/plplot_cmake_test cmake $prefix/share/plplot$plplot_version/examples make -j<parallel_build_number> test_noninteractive >& test_noninteractive.out # Legacy-based build system for the installed examples # Keep the install-tree clean by copying the installed examples elsewhere cp -a $prefix/share/plplot$plplot_version/examples /tmp cd /tmp/examples make -j<parallel_build_number> test_noninteractive >& test_noninteractive.out If the above tests work on Fedora that proves that the Fedora PLplot installation has correctly configured CMake export and pkg-config *.pc files for the final Fedora installation locations. Currently such tests fail for Ole's Debian packages, but I think some attention to the details of PLplot installation locations will solve this issue. And similarly in your case if those tests fail for Fedora. 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 __________________________ |
|
From: Orion P. <or...@nw...> - 2018-11-25 02:07:09
|
On 11/24/18 11:55 AM, Alan W. Irwin wrote: > Hi Orion: > > This thread has previously been directed mostly at Ole, but > I am including you now because I think it will interest you. It > concerns the > problems (one of them upstream which I plan to fix soon by factoring > the export files [as I promised you long ago, but it got lost on the > stack until Ole ran into this problem again!]) that Ole has been having > with Debian to get testing working properly for the installed > examples. > > I would appreciate you contributing to this thread. For example, if > all Fedora binary packages are installed (which works around the above > factoring problem until I can get it fixed) do the following tests of the > CMake-based and legacy-based installed examples work? > > # CMake-based build system for the installed examples > # Move to initially empty build tree first. > rm -rf /tmp/plplot_cmake_test > mkdir /tmp/plplot_cmake_test > cd /tmp/plplot_cmake_test > cmake $prefix/share/plplot$plplot_version/examples > make -j<parallel_build_number> test_noninteractive >& > test_noninteractive.out > > # Legacy-based build system for the installed examples > # Keep the install-tree clean by copying the installed examples elsewhere > cp -a $prefix/share/plplot$plplot_version/examples /tmp > cd /tmp/examples > make -j<parallel_build_number> test_noninteractive >& > test_noninteractive.out > > If the above tests work on Fedora that proves that the Fedora > PLplot installation has correctly configured CMake export > and pkg-config *.pc files for the final Fedora installation locations. > > Currently such tests fail for Ole's Debian packages, but I think some > attention to the details of PLplot installation locations will solve this > issue. And similarly in your case if those tests fail for Fedora. > > Alan It mostly seems to work fine. The one strange error for cmake is: Generate C results for bmpqt file device /usr/share/plplot5.13.0/examples/test_lua.sh: line 50: lua_svg_test.error: Permission denied [ 92%] Built target xtraditional16a cat: lua_svg_test.error: No such file or directory make[3]: *** [CMakeFiles/test_lua_svg.dir/build.make:374: test_examples_output_dir/x00lua01.svg] Error 1 and for make/pkgconfig: Generate Octave results for svg device ./plplot-test.sh --verbose --front-end=octave --device=svg /usr/bin/bash: ./plplot-test.sh: Permission denied make: *** [Makefile:126: x01o01.svg] Error 126 which is due to my removing the executable bit for the example script to avoid issues with automatic dependencies. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nw... Boulder, CO 80301 https://www.nwra.com/ |
|
From: Alan W. I. <Ala...@gm...> - 2018-11-25 07:46:21
|
On 2018-11-24 19:06-0700 Orion Poplawski wrote:
> On 11/24/18 11:55 AM, Alan W. Irwin wrote:
>> Hi Orion:
>>
>> This thread has previously been directed mostly at Ole, but
>> I am including you now because I think it will interest you. It concerns
>> the
>> problems (one of them upstream which I plan to fix soon by factoring
>> the export files [as I promised you long ago, but it got lost on the
>> stack until Ole ran into this problem again!]) that Ole has been having
>> with Debian to get testing working properly for the installed
>> examples.
>>
>> I would appreciate you contributing to this thread. For example, if
>> all Fedora binary packages are installed (which works around the above
>> factoring problem until I can get it fixed) do the following tests of the
>> CMake-based and legacy-based installed examples work?
>>
>> # CMake-based build system for the installed examples
>> # Move to initially empty build tree first.
>> rm -rf /tmp/plplot_cmake_test
>> mkdir /tmp/plplot_cmake_test
>> cd /tmp/plplot_cmake_test
>> cmake $prefix/share/plplot$plplot_version/examples
>> make -j<parallel_build_number> test_noninteractive >&
>> test_noninteractive.out
>>
>> # Legacy-based build system for the installed examples
>> # Keep the install-tree clean by copying the installed examples elsewhere
>> cp -a $prefix/share/plplot$plplot_version/examples /tmp
>> cd /tmp/examples
>> make -j<parallel_build_number> test_noninteractive >&
>> test_noninteractive.out
>>
>> If the above tests work on Fedora that proves that the Fedora
>> PLplot installation has correctly configured CMake export
>> and pkg-config *.pc files for the final Fedora installation locations.
>>
>> Currently such tests fail for Ole's Debian packages, but I think some
>> attention to the details of PLplot installation locations will solve this
>> issue. And similarly in your case if those tests fail for Fedora.
>>
>> Alan
>
> It mostly seems to work fine. The one strange error for cmake is:
>
> Generate C results for bmpqt file device
> /usr/share/plplot5.13.0/examples/test_lua.sh: line 50: lua_svg_test.error:
> Permission denied
> [ 92%] Built target xtraditional16a
> cat: lua_svg_test.error: No such file or directory
> make[3]: *** [CMakeFiles/test_lua_svg.dir/build.make:374:
> test_examples_output_dir/x00lua01.svg] Error 1
>
> and for make/pkgconfig:
>
> Generate Octave results for svg device
> ./plplot-test.sh --verbose --front-end=octave --device=svg
> /usr/bin/bash: ./plplot-test.sh: Permission denied
> make: *** [Makefile:126: x01o01.svg] Error 126
>
> which is due to my removing the executable bit for the example script to
> avoid issues with automatic dependencies.
Hi Orion:
I am glad to hear you appear to have what appear to be only two minor
issues flawing complete success with the above tests.
N.B. I regret now specifying the /tmp directory for both tests since that might get overflowed
by the ~3GB of files that are produced by each of these tests when they are successful.
So modify my instructions above to create an initially empty build directory under your home
directory for the CMake-based case, and cp the installed example tree to an initially empty
examples directory under your home directory.
Here are my comments on those two issues.
I. For CMake-based build system for the installed examples, issue with lua_svg_test.error: Permission denied.
Just to remind you, official Debian lua version 5.3.3 (but not Fedora Lua 5.3.5) has a really bad bug
that can only be avoided by using a home-built 5.3.5 (which I use for my testing).
So in my results the lua location will look quite different than yours.
Line 50 of the configured test.lua.sh file in my case is
/home/software/lua/install-5.3.5/bin/lua x${index}.${lang} -dev $device -o "${results}"/x${index}${lang}%n.$dsuffix \
$options 2> lua_${device}_test.error >| "${results}"/x${index}${lang}_${dsuffix}.txt
So my guess is in your case the equivalent lua command is having trouble gaining permissions to write
to /tmp. To check that try running
lua test.lua 2> test.stderr >| test.stdout
in /tmp and also your home directory where
test.lua simply writes separate test strings to stderr and stdout.
Of course, if /tmp was overflowing doing the same test under your home directory might cure the
issue.
II. For legacy build system for the installed examples, issue with ./plplot-test.sh: Permission denied
The configured and installed (in <prefix>/share/plplot5.13.0/examples)
test scripts in my case have the following permissions
software@merlin> ls -lt *.sh
-rwxr-xr-x 1 software software 14080 Oct 27 12:16 plplot-test-interactive.sh*
-rwxr-xr-x 1 software software 13782 Oct 27 12:16 plplot-test.sh*
-rwxr-xr-x 1 software software 2211 Oct 27 12:16 test_ada.sh*
-rwxr-xr-x 1 software software 2326 Oct 27 12:16 test_c.sh*
-rwxr-xr-x 1 software software 2981 Oct 27 12:16 test_c_interactive.sh*
-rwxr-xr-x 1 software software 2802 Oct 27 12:16 test_cxx.sh*
-rwxr-xr-x 1 software software 2427 Oct 27 12:16 test_d.sh*
-rwxr-xr-x 1 software software 7150 Oct 27 12:16 test_diff.sh*
-rwxr-xr-x 1 software software 2965 Oct 27 12:16 test_fortran.sh*
-rwxr-xr-x 1 software software 2898 Oct 27 12:16 test_java.sh*
-rwxr-xr-x 1 software software 2645 Oct 27 12:16 test_lua.sh*
-rwxr-xr-x 1 software software 2176 Oct 27 12:16 test_ocaml.sh*
-rwxr-xr-x 1 software software 3662 Oct 27 12:16 test_octave.sh*
-rwxr-xr-x 1 software software 4221 Oct 27 12:16 test_octave_interactive.sh*
-rwxr-xr-x 1 software software 2337 Oct 27 12:16 test_python.sh*
-rwxr-xr-x 1 software software 4556 Oct 27 12:16 test_tcl.sh*
Yours should as well since that executable permission bit is essential for all of
them to work. So I hope you have a cunning scheme in mind to work
around your package dependency issue another way rather then removing
any/all of these essential executable bits.
And, in this case also, this test should be done in your home directory and
not /tmp.
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
__________________________
|
|
From: Alan W. I. <Ala...@gm...> - 2018-11-11 02:17:53
|
On 2018-11-09 23:16+0100 Ole Streicher wrote: > Hi, > > in the Debian package, we usually try to run CI tests regularly on each > dependency change. This gives us the opportunity to early find problems > with the package or one of its dependencies. > > However, I have some difficulties to do that; this may be connected with > my limited knowledge of cmake. > > The test is started with the binaries installed in the system and the > sources unpacked. The working dir is the root of the sources. > > What I basically do now is to run the following script: > > --------------------8<--------------------- > #!/bin/sh > > set -e > > SRC=$(pwd) > > test_dir=$(mktemp -d) > > cd $test_dir > cmake $SRC/examples > > make test_diff_psc > make test_noninteractive > --------------------8<--------------------- > > However, the "cmake" step fails with > > --------------------8<--------------------- > [...] > -- CMAKE_SYSTEM_NAME = Linux > -- CMAKE_PLATFORM_INFO_DIR = /tmp/tmp.TwEFoteIXX/CMakeFiles/3.12.3 > CMake Error at CMakeLists.txt:469 (include): > include could not find load file: > > plplot_configure > --------------------8<--------------------- > > How could I fix this? Hi Ole: Everything you have done above should work fine for building and testing the installed examples using the CMake-based build system for those examples. For example, similar tests here are normally successful, and that error message has never occurred here. So looking deeper, it turns out that include(plplot_configure) is a command that occurs in the installed CMakeLists.txt file in the top-level source directory for the installed examples, SRC=/usr/share/plplot5.13.0/examples (although that 13 will change to 14 when 5.14.0 is released). That command is looking for $SRC/cmake/modules/plplot_configure.cmake which normally is installed by PLplot. So since the error message says that installed file cannot be found, I strongly suspect the problem is simply that your RPM needs updating to include that installed file in the manifest. So please let me know if (a) $SRC/cmake/modules/plplot_configure.cmake is actually installed and if not (b) whether my guess is correct that the incompleteness of the rpm manifest is the issue. Best wishes, 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 __________________________ |
|
From: Alan W. I. <Ala...@gm...> - 2018-11-15 09:11:01
|
On 2018-11-13 18:23+0100 Ole Streicher wrote:
> Hi Alan,
>
> On 11.11.18 03:17, Alan W. Irwin wrote:
>> Everything you have done above should work fine for building and
>> testing the installed examples using the CMake-based build system for
>> those examples.
>
> My problem is that I have actually split the examples by the language
> binding: C and C++ go to libplplot-dev, tcl goes to plplot-tcl-dev etc.
> It looks that this is not a really smart idea, right?
>
> It also implies that they are not all at the same place: Debian
> filesystem rules require that the examples are installed under
> /usr/share/doc/<package>/examples (and they are partially zipped in the
> moment).
>
> Can I re-create the cmake files required for the tests somehow from the
> source? Then I could avoid a bigger restructuration of the packages.
Hi Ole:
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.
Then *if* you install all binary PLplot packages (with those examples
removed from then) and that plplot_examples package, then the
test procedure I suggested before for those installed examples should
"just work". So would you be willing to reorganize your packages that way and
verify the tests are working for that case?
That is a good "proof-of-concept first step to make sure we are at the same
starting point, but the obvious issue with that step is plplot-examples depends on all
plplot binary packages, i.e., it won't work unless all are installed.
The rest of this e-mail concerns two up-stream fixes which I plan to
work on after the 5.14.0 release to relax that constraint.
As I have said before, the key command in the top-level CMakeList.txt
file for the installed examples is
find_package(plplot)
That command uses the exported files (located for
the Debian Buster libplplot-dev package at
libplplot-dev: /usr/lib/x86_64-linux-gnu/cmake/plplot/plplotConfig.cmake
libplplot-dev: /usr/lib/x86_64-linux-gnu/cmake/plplot/export_plplot.cmake
libplplot-dev: /usr/lib/x86_64-linux-gnu/cmake/plplot/export_plplot-none.cmake
) to implement imported targets such as PLPLOT:plplot,
PLPLOT:plplotcxx, etc., and our build system for the installed
examples then goes on to use those imported targets to build and test
the examples.
However, suppose a user only installs a subset of the configured
components of PLplot. To get the installed examples build system to
work for that case I need to implement the following two upstream
upgrades:
1. I need to factor the exported target files, e.g., the two
export_plplot* files mentioned above. Such factoring had already been
highly recommended to me by CMake gurus, and I think it should be
entirely straightforward.
Instead of using the "EXPORT export_plplot" signature for all library
and shared object installs and exporting all of that information to
just the two files export_plplot.cmake and export_plplot-none.cmake
using
install(EXPORT export_plplot DESTINATION ${LIB_DIR}/cmake/plplot NAMESPACE ${PROJECT_NAMESPACE})
I simply use the "EXPORT export_<target_name>" signature for all
library and shared object installs, and for each of those I add a
install(EXPORT export_<target_name> DESTINATION ${LIB_DIR}/cmake/plplot NAMESPACE ${PROJECT_NAMESPACE})
The net result will be two files per target installed with names
export_<target_name>.cmake and export_<target_name>-none.cmake
where the first one automatically includes the second.
Also, I will need to change the plplotConfig.cmake file to use the
OPTIONAL signature of the cmake command "include" for a list of every
possible export_<target_name>.cmake file to include just those that
are currently installed. But that change is completely
straightforward.
To take advantage of this factoring, you would also have to reorganize
what is in your binary packages a small amount. For example,
libplplot15 which currently includes
libplplot15: /usr/lib/x86_64-linux-gnu/plplot5.13.0/drivers/svg.so
should also need to contain the export files export_svg.cmake and
export_svg-none.cmake that are now would be associated with that
shared object. And similarly for all packages that contain installed
libraries and shared objects.
As a result of this factoring and your package reorganization to
include the many export_<target_name>.cmake and
export_<target_name>-none.cmake files generated by that factoring in
the correct binary packages, the "find_package(plplot)" command
mentioned above should just create the subset of the imported targets that
correspond to the subset of PLplot binary packages that are
installed by the user.
2. Currently the installed examples generally just check if a given
component has been configured in the core build, by, e.g., checking
ENABLE_cxx. But with some of those configured components potentially
missing because a user did not install all plplot binary packages such
a check is not correct and needs to be replaced by a test for the
existence of the exported target, e.g., PLPLOT::plplotcxx. These
sorts of changes should also be straightforward.
So since both upstream improvements are straightforward I plan to do
both some time relatively soon after the release of 5.14.0, and I hope
soon after that is your tests of the plplot-examples package (with the
Depends: in the proof-of-concept replaced by Suggested: in the final
package result) just work regardless of which suggested PLplot binary
packages are installed.
Best wishes,
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
__________________________
|
|
From: Ole S. <deb...@li...> - 2018-11-22 19:54:35
|
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. Is there a way to switch off the consistency check for Python? BTW, I would still keep the dependencies of the -doc package as they are, and only for the tests install everything. Cheers Ole |
|
From: Alan W. I. <Ala...@gm...> - 2018-11-23 00:05:53
|
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 __________________________ |
|
From: Ole S. <deb...@li...> - 2018-11-23 07:28:54
Attachments:
CMakeOutput.log
|
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
|
|
From: Alan W. I. <Ala...@gm...> - 2018-11-23 21:17:36
|
On 2018-11-23 08:28+0100 Ole Streicher wrote: [...] > 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? Hi Ole: I think there are at least two issues above. I. Missing package Everything above leading up to -- WARNING: Qt5 core build-tree and install-tree inconsistency indicates there is an inconsistency between the environment you used to build and install PLplot and the environment you are using to test the installed examples tree. From the first set of messages, especially, Failed to find Qt5 component "Svg" config file at "/usr/lib/x86_64-linux-gnu/cmake/Qt5Svg/Qt5SvgConfig.cmake" I think the solution is you must install libqt5svg5-dev which apt-file tells me contains /usr/lib/x86_64-linux-gnu/cmake/Qt5Svg/Qt5SvgConfig.cmake. II. The second problem above starts with the message CMake Error at /usr/lib/x86_64-linux-gnu/cmake/plplot/export_plplot.cmake:279 (message) I am virtually positive what is going on is that PLplot installs the files corresponding to the exported target PLPLOT::_Pltk_init.so in one location, e.g., "/usr/lib/python2.7/dist-packages/_Pltk_init.so" and your Debian packaging automatically changes that location to something else creating an inconsistency between the location expected by the exported target, and the location where the file was installed. To avoid such exported target inconsistent location issues, it is imperative that you change the *PLplot* installation locations to the locations expected by Debian. Please look at your core build (not the build of the installed examples you were testing above) cmake output for instructions about how to get PLplot to modify installation locations. For example, here is the relevant part of my cmake output: -----------------------------------------------8<------------------------------------- Summary of CMake build system results for PLplot Install location variables which can be set by the user. N.B. These variables are ordered by decreasing degree of generality, with the _default_ values of the later ones in the list determined by the values of variables earlier in the list. So, for example, it is usually sufficient in the vast majority of cases to just set CMAKE_INSTALL_PREFIX, and the rest of these variables are adjusted accordingly (at least for a fresh configuration), and it is rare indeed that is is necessary for a user to set any variable here whose name does not start with "CMAKE_INSTALL_". CMAKE_INSTALL_PREFIX: /home/software/plplot/installcmake CMAKE_INSTALL_EXEC_PREFIX: /home/software/plplot/installcmake CMAKE_INSTALL_BINDIR: /home/software/plplot/installcmake/bin CMAKE_INSTALL_DATADIR: /home/software/plplot/installcmake/share CMAKE_INSTALL_LIBDIR: /home/software/plplot/installcmake/lib CMAKE_INSTALL_INCLUDEDIR: /home/software/plplot/installcmake/include CMAKE_INSTALL_INFODIR: /home/software/plplot/installcmake/share/info CMAKE_INSTALL_MANDIR: /home/software/plplot/installcmake/share/man CMAKE_INSTALL_PKG_CONFIG_DIR: /home/software/plplot/installcmake/lib/pkgconfig DATA_DIR: /home/software/plplot/installcmake/share/plplot5.13.0 LIB_DIR: /home/software/plplot/installcmake/lib INCLUDE_DIR: /home/software/plplot/installcmake/include/plplot BIN_DIR: /home/software/plplot/installcmake/bin DRV_DIR: /home/software/plplot/installcmake/lib/plplot5.13.0/drivers DOC_DIR: /home/software/plplot/installcmake/share/doc/plplot INFO_DIR: /home/software/plplot/installcmake/share/info MAN_DIR: /home/software/plplot/installcmake/share/man PKG_CONFIG_DIR: /home/software/plplot/installcmake/lib/pkgconfig FORTRAN_MOD_DIR: /home/software/plplot/installcmake/lib/fortran/modules/plplot JAR_DIR: /home/software/plplot/installcmake/share/java JAVAWRAPPER_DIR: /home/software/plplot/installcmake/lib/jni PYTHON_INSTDIR: /home/software/plplot/installcmake/lib/python3.6/site-packages PLPLOT_OCTAVE_DIR: /home/software/plplot/installcmake/share/plplot_octave OCTAVE_M_DIR: /home/software/plplot/installcmake/share/octave/site/m/PLplot OCTAVE_OCT_DIR: /home/software/plplot/installcmake/lib/octave TCL_DIR: /home/software/plplot/installcmake/share/plplot5.13.0/tcl ADA_INCLUDE_DIR: /home/software/plplot/installcmake/share/ada/adainclude/plplotada ADA_LIB_DIR: /home/software/plplot/installcmake/lib/ada/adalib/plplotada LUA_DIR: /home/software/plplot/installcmake/lib/lua/plplot OCAML_INSTALL_DIR: /home/software/plplot/installcmake/lib/ocaml -----------------------------------------------8<------------------------------------- Of course, your own list of install locations will be quite different (since I am using a a completely different installation prefix than you), but your should modify your list (e.g., by setting -DCMAKE_INSTALL_LIBDIR=<Debian library install location> -DPYTHON_INSTDIR=<Debian Python install location) in your core build so that your Debian packager does not have to change *any* file location installed by PLplot which then forces the exported targets for the install to have the correct file locations. 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 __________________________ |
|
From: Ole S. <deb...@li...> - 2018-11-26 15:47:02
|
Hi Alan, On 23.11.18 22:17, Alan W. Irwin wrote: > On 2018-11-23 08:28+0100 Ole Streicher wrote: >> -- 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: That was actually my fault; I didn't install all plplot packages. >> 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: This however remains. > II. The second problem above starts with the message > > CMake Error at > /usr/lib/x86_64-linux-gnu/cmake/plplot/export_plplot.cmake:279 (message) > > I am virtually positive what is going on is that PLplot installs the > files corresponding to the exported target PLPLOT::_Pltk_init.so in > one location, e.g., "/usr/lib/python2.7/dist-packages/_Pltk_init.so" > and your Debian packaging automatically changes that location to > something else creating an inconsistency between the location expected > by the exported target, and the location where the file was installed. Hmm, no. It installs the file on the expected place, but *after* this (just before the files are put into the package), its name is changed to_Pltk_init.x86_64-linux-gnu.so (so, the architecture triple is added). Similarly for _plplotc.so (to _plplotc.x86_64-linux-gnu.so) and for the Python 3 shared libs (there, the name contains the Python version as well). So, it is not an inconsistent location, but a different file name. > Please look at your core build (not the build of the installed > examples you were testing above) cmake output for instructions about > how to get PLplot to modify installation locations. For example, here > is the relevant part of my cmake output: > > -----------------------------------------------8<------------------------------------- > > CMAKE_INSTALL_PREFIX: /home/software/plplot/installcmake > CMAKE_INSTALL_EXEC_PREFIX: /home/software/plplot/installcmake > CMAKE_INSTALL_BINDIR: /home/software/plplot/installcmake/bin > CMAKE_INSTALL_DATADIR: /home/software/plplot/installcmake/share > CMAKE_INSTALL_LIBDIR: /home/software/plplot/installcmake/lib > CMAKE_INSTALL_INCLUDEDIR: /home/software/plplot/installcmake/include > CMAKE_INSTALL_INFODIR: /home/software/plplot/installcmake/share/info > CMAKE_INSTALL_MANDIR: /home/software/plplot/installcmake/share/man > CMAKE_INSTALL_PKG_CONFIG_DIR: > /home/software/plplot/installcmake/lib/pkgconfig > DATA_DIR: /home/software/plplot/installcmake/share/plplot5.13.0 > LIB_DIR: /home/software/plplot/installcmake/lib > INCLUDE_DIR: /home/software/plplot/installcmake/include/plplot > BIN_DIR: /home/software/plplot/installcmake/bin > DRV_DIR: /home/software/plplot/installcmake/lib/plplot5.13.0/drivers > DOC_DIR: /home/software/plplot/installcmake/share/doc/plplot > INFO_DIR: /home/software/plplot/installcmake/share/info > MAN_DIR: /home/software/plplot/installcmake/share/man > PKG_CONFIG_DIR: /home/software/plplot/installcmake/lib/pkgconfig > FORTRAN_MOD_DIR: > /home/software/plplot/installcmake/lib/fortran/modules/plplot > JAR_DIR: /home/software/plplot/installcmake/share/java > JAVAWRAPPER_DIR: /home/software/plplot/installcmake/lib/jni > PYTHON_INSTDIR: > /home/software/plplot/installcmake/lib/python3.6/site-packages > PLPLOT_OCTAVE_DIR: /home/software/plplot/installcmake/share/plplot_octave > OCTAVE_M_DIR: /home/software/plplot/installcmake/share/octave/site/m/PLplot > OCTAVE_OCT_DIR: /home/software/plplot/installcmake/lib/octave > TCL_DIR: /home/software/plplot/installcmake/share/plplot5.13.0/tcl > ADA_INCLUDE_DIR: > /home/software/plplot/installcmake/share/ada/adainclude/plplotada > ADA_LIB_DIR: /home/software/plplot/installcmake/lib/ada/adalib/plplotada > LUA_DIR: /home/software/plplot/installcmake/lib/lua/plplot > OCAML_INSTALL_DIR: /home/software/plplot/installcmake/lib/ocaml > -----------------------------------------------8<------------------------------------- That looks reasonable, see f.e. https://buildd.debian.org/status/fetch.php?pkg=plplot&arch=amd64&ver=5.13.0%2Bdfsg-9&stamp=1538607430&raw=0 -----------------------------------------------8<------------------------------------- CMAKE_INSTALL_PREFIX: /usr CMAKE_INSTALL_EXEC_PREFIX: /usr CMAKE_INSTALL_BINDIR: /usr/bin CMAKE_INSTALL_DATADIR: /usr/share CMAKE_INSTALL_LIBDIR: /usr/lib/x86_64-linux-gnu CMAKE_INSTALL_INCLUDEDIR: /usr/include CMAKE_INSTALL_INFODIR: /usr/share/info CMAKE_INSTALL_MANDIR: /usr/share/man CMAKE_INSTALL_PKG_CONFIG_DIR: /usr/lib/x86_64-linux-gnu/pkgconfig DATA_DIR: /usr/share/plplot5.13.0 LIB_DIR: /usr/lib/x86_64-linux-gnu INCLUDE_DIR: /usr/include/plplot BIN_DIR: /usr/bin DRV_DIR: /usr/lib/x86_64-linux-gnu/plplot5.13.0/drivers DOC_DIR: /usr/share/doc/plplot INFO_DIR: /usr/share/info MAN_DIR: /usr/share/man PKG_CONFIG_DIR: /usr/lib/x86_64-linux-gnu/pkgconfig FORTRAN_MOD_DIR: /usr/lib/x86_64-linux-gnu/fortran/modules/plplot JAR_DIR: /usr/share/java JAVAWRAPPER_DIR: /usr/lib/x86_64-linux-gnu/jni PYTHON_INSTDIR: /usr/lib/python3/dist-packages PLPLOT_OCTAVE_DIR: /usr/share/plplot_octave OCTAVE_M_DIR: /usr/share/octave/site/m/PLplot OCTAVE_OCT_DIR: /usr/lib/x86_64-linux-gnu/octave/site/oct/api-v52/x86_64-pc-linux-gnu TCL_DIR: /usr/share/plplot5.13.0/tcl ADA_INCLUDE_DIR: /usr/share/ada/adainclude/plplotada ADA_LIB_DIR: /usr/lib/x86_64-linux-gnu/ada/adalib/plplotada LUA_DIR: /usr/lib/x86_64-linux-gnu/lua/5.1/plplot OCAML_INSTALL_DIR: /usr/lib/ocaml -----------------------------------------------8<------------------------------------- (The Python install dir is patched, since I build both Python 2 and 3 packages) Best Ole |
|
From: Alan W. I. <Ala...@gm...> - 2018-11-26 18:52:50
|
On 2018-11-26 16:46+0100 Ole Streicher wrote: > Hmm, no. It installs the file on the expected place, but *after* this > (just before the files are put into the package), its name is changed > to_Pltk_init.x86_64-linux-gnu.so (so, the architecture triple is added). > Similarly for _plplotc.so (to _plplotc.x86_64-linux-gnu.so) and for the > Python 3 shared libs (there, the name contains the Python version as well). > > So, it is not an inconsistent location, but a different file name. It appears that CMake hard codes the filename on export. For example, software@merlin> grep _Pltk_init.so export_plplot-noconfig.cmake IMPORTED_LOCATION_NOCONFIG "/home/software/plplot/HEAD/comprehensive_test_disposeable blank/shared/noninteractive/install_tree/lib/python3.6/site-packages/_Pltk_init.so" list(APPEND _IMPORT_CHECK_FILES_FOR_PLPLOT::_Pltk_init "/home/software/plplot/HEAD/comprehensive_test_disposeable blank/shared/noninteractive/install_tree/lib/python3.6/site-packages/_Pltk_init.so" ) where export_plplot-noconfig.cmake is (on my system) installed in the $prefix/lib/cmake/plplot directory. And you will find similar hard-coded filenames for all other libraries and shared objects (dll's) in that file. To solve this I suggest you simply use a sed script to add the architecture triple expected by Debian for the relevant filenames in the above file. Good luck with that suggested change and let me know how it goes. 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 __________________________ |
|
From: Alan W. I. <Ala...@gm...> - 2018-11-27 21:40:43
|
On 2018-11-27 13:44+0100 Ole Streicher wrote: > Hi Alan, > > thanks for the help so far! Hi Ole: You are welcome. > > On 26.11.18 19:52, Alan W. Irwin wrote: >> On 2018-11-26 16:46+0100 Ole Streicher wrote: >> It appears that CMake hard codes the filename on export. For example, >> >> software@merlin> grep _Pltk_init.so export_plplot-noconfig.cmake >> IMPORTED_LOCATION_NOCONFIG >> "/home/software/plplot/HEAD/comprehensive_test_disposeable >> blank/shared/noninteractive/install_tree/lib/python3.6/site-packages/_Pltk_init.so" >> >> list(APPEND _IMPORT_CHECK_FILES_FOR_PLPLOT::_Pltk_init >> "/home/software/plplot/HEAD/comprehensive_test_disposeable >> blank/shared/noninteractive/install_tree/lib/python3.6/site-packages/_Pltk_init.so" >> ) >> >> where export_plplot-noconfig.cmake is (on my system) installed in the >> $prefix/lib/cmake/plplot directory. And you will find similar >> hard-coded filenames for all other libraries and shared objects >> (dll's) in that file. > > I now just remove the checks via sed: > > sed > '/\/_Pltk_init.so/d;/\/_plplotc.so/d;/\/plplot_pyqt5_/d;/\/libplplotada.so/d' > \ > -i /usr/lib/*/cmake/plplot/export_plplot-none.cmake > > And I also removed them from the dependencies in CMakeList.txt of the > examples subdir. This is not a good idea. I haven't checked deeply, but our build and test system for the installed examples may use the location property of the imported PLPLOT::_Pltk_init target which you have removed with the above step. Or we may make such a change later. So if this is not an issue now, it is "an accident waiting to happen". So I strongly suggest instead you fix this properly by using your sed command to replace (not remove) _Pltk_init.so with the correct Debianized name for that installed file. > Then, cmake runs fine But the "make" command gives errors after 8% > completion: > > --------------------------8<----------------------------------------- > x19c > > *** PLPLOT ERROR, ABORTING OPERATION *** > Could not find ss/ss64ne_Landform_Area file., aborting operation > [... repeating the same warning for different files] > > *** PLPLOT ERROR, ABORTING OPERATION *** > Could not find ss/ss64ne_General_Text file., aborting operation > make[3]: *** [CMakeFiles/test_c_svgqt.dir/build.make:294: > test_examples_output_dir/x00c01.svgqt] Fehler 1 > --------------------------8<----------------------------------------- A recent install of mine has the following shapelib data files installed in $prefix/share/plplot$version/ss os_open_conditions.txt ss64ne_Height_Contours.dbf ss64ne_Landform_Line.prj ss64ne_Water_Area.shp ss64ne_Building_Area.dbf ss64ne_Height_Contours.prj ss64ne_Landform_Line.shp ss64ne_Water_Area.shx ss64ne_Building_Area.prj ss64ne_Height_Contours.shp ss64ne_Landform_Line.shx ss64ne_Water_Line.dbf ss64ne_Building_Area.shp ss64ne_Height_Contours.shx ss64ne_Road_Centreline.dbf ss64ne_Water_Line.prj ss64ne_Building_Area.shx ss64ne_Landform_Area.dbf ss64ne_Road_Centreline.prj ss64ne_Water_Line.shp ss64ne_General_Text.dbf ss64ne_Landform_Area.prj ss64ne_Road_Centreline.shp ss64ne_Water_Line.shx ss64ne_General_Text.prj ss64ne_Landform_Area.shp ss64ne_Road_Centreline.shx ss64ne_General_Text.shp ss64ne_Landform_Area.shx ss64ne_Water_Area.dbf ss64ne_General_Text.shx ss64ne_Landform_Line.dbf ss64ne_Water_Area.prj Example 19 depends on these map data so these files are absolutely necessary for example 19 to work. Also, I believe we have had some discussion in the past on the licensing of these files, and I am positive you were satisfied on that issue. An apt-file search for these files here tells me they have not been included in the past in Debian PLplot packages (likely because of unclear licensing concerns which we have addressed), but once you address that issue, the above errors should go away. And that change (and the sed command change I recommended above) might be all you need to do to have a complete test success since the above error occurring for example 19 means almost half the standard examples work fine for you now. And, yes, I am a "glass half full" rather than "glass half empty" kind of guy. :-) 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 __________________________ |
|
From: Alan W. I. <Ala...@gm...> - 2018-11-30 01:42:39
|
On 2018-11-29 13:33+0100 Ole Streicher wrote:
[...]
> Now, all C examples pass.
Excellent!
> For ADA, I now however get
>
> [ 11%] Built target test_c_psc
> Scanning dependencies of target xstandard16a
> [ 11%] Building Ada object ada/CMakeFiles/xstandard16a.dir/xstandard16a.o
> make[3]: *** Keine Regel vorhanden, um das Ziel „plplotada-NOTFOUND“,
> benötigt von „ada/xstandard16a“, zu erstellen. Schluss.
> make[2]: *** [CMakeFiles/Makefile2:5655:
> ada/CMakeFiles/xstandard16a.dir/all] Fehler 2
> make[1]: *** [CMakeFiles/Makefile2:387:
> CMakeFiles/test_noninteractive.dir/rule] Fehler 2
>
The build of xstandard* examples is configured by the CMake logic in
examples/ada/CMakeLists.txt.
I am pretty sure the relevant CMake logic lines to build the Ada examples in that file for this case where it is not the CORE_BUILD are
set(adalinkflags "\"-aI${CMAKE_CURRENT_SOURCE_DIR}\" \"-aI${ADA_INCLUDE_DIR}\" \"-aL${ADA_LIB_DIR}\"")
[...]
set_target_properties(${TARGET_NAME} PROPERTIES LINK_FLAGS ${adalinkflags})
target_link_libraries(${TARGET_NAME} PLPLOT::plplotada PLPLOT::plplot)
So are the install locations ${ADA_INCLUDE_DIR} and ${ADA_LIB_DIR} set
where your Debian package actually installs Ada files? And if you
look in the PLplot export file, is the PLPLOT::plplotada location
property set there consistent with the full pathname of the plplotada
library that is installed by your debian package?
If those hints don't solve it or if they do solve it but another error
is encountered, please use a clean start (i.e., an initially empty
build tree), and send me the the complete cmake output and also the
complete results of
make VERBOSE=1 test_noninteractive >& test_noninteractive.out
(i.e., without any parallel build options).
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
__________________________
|
|
From: Alan W. I. <Ala...@gm...> - 2018-12-06 22:32:22
|
On 2018-12-06 14:41+0100 Ole Streicher wrote: > Hi Alan, > > sorry for the delay; I now managed to adjust and run the test suite on > the installed package. I'll attach the full log; commands were > > $ cmake /usr/share/doc/plplot-doc/examples/ > $ make VERBOSE=1 test_noninteractive > > I needed to downgrade to cmake 3.12; see bug #191. Hi Ole: I am glad to hear you are so close to complete success. My recent comprehensive test with 3.13.1 works perfectly here for Debian Buster and the git master tip version of PLplot. That master tip version includes a fix for bug 191 so could you confirm that by trying the master tip version (and then closing that bug if that indeed fixes it)? > The only remaining > errors are now ADA errors: > > Building Ada object ada/CMakeFiles/xstandard16a.dir/xstandard16a.o > make[3]: *** No rule to make target 'plplotada-NOTFOUND', needed by > 'ada/xstandard16a'. My recent comprehensive test using cmake-3.13.1 had no such Ada issue. So very likely this issue is because your installation is missing the plplotada *.so file or *.so.*.* file it links to, or this issue is an artifact of the way Debian packaging software changes locations or *.so names to some special Debian package naming scheme. So to debug this final issue do the following: * Make sure you are using the PLplot master tip version so we are on the same page with regard to bug fixes. This is really important since many 5.13.0 bugs are fixed in master tip which is now very close to 5.14.0. (I am now in the process of updating the release notes for that forthcoming release.) * Make sure your Ada binary package or packages are installed, and in those you should find the full pathname of the plplotada *.so file that should be installed by that package. * Check the Ada information in your installed and sed-transformed export files for consistency with that full pathname. If there is an Ada install directory inconsistency, then adjustment of the Ada install location you use for your core build should fix that. If there is a name inconsistency, then you need to make that consistent with some special Debian naming scheme for Ada *.so files by transforming our export files with a sed script. You told me of one such naming inconsistency you discovered before for a python related *.so file, and this may be just one other instance of the problem or all *.so files may have names that are inconsistent with the actual install name. In all cases if the *.so file name (without the path) does not match what is actually installed, a sed script should correct that inconsistency. Otherwise, it is "an accident waiting to happen" as appears to be the case both for that *.so Python module and now the Ada *.so file. If those steps don't help you to completely resolve this matter, please collect the following information and send it to me. (i) The complete list of files in your Ada binary packages (presumably some rpm command will generate that), (ii) the output from the cmake command you used *for the core build*, and (iii) the actual original and sed-modified export files. I am virtually positive that information will be sufficient for me to figure out what is wrong. 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 __________________________ |
|
From: Alan W. I. <Ala...@gm...> - 2018-12-18 21:17:00
|
On 2018-11-15 01:10-0800 Alan W. Irwin wrote: [...] > I need to implement the following two upstream > upgrades: > > 1. I need to factor the exported target files, e.g., the two > export_plplot* files mentioned above. Such factoring had already been > highly recommended to me by CMake gurus, and I think it should be > entirely straightforward. [...] > 2. Currently the installed examples generally just check if a given > component has been configured in the core build, by, e.g., checking > ENABLE_cxx. But with some of those configured components potentially > missing because a user did not install all plplot binary packages such > a check is not correct and needs to be replaced by a test for the > existence of the exported target, e.g., PLPLOT::plplotcxx. These > sorts of changes should also be straightforward. To Ole and Orion: Here is the current status of these proposed upstream changes. As of commit plplot-5.14.0-10-g66d68d93e I have implemented (and thoroughly tested) the first upgrade above. Because of this change, the list of export-related files (for my normal case of a fully loaded Debian Testing platform where I don't specify a build configuration) has now expanded to the following: export__Pltk_init-noconfig.cmake export__Pltk_init.cmake export__plplotc-noconfig.cmake export__plplotc.cmake export_cairo-noconfig.cmake export_cairo.cmake export_csirocsa-noconfig.cmake export_csirocsa.cmake export_csironn-noconfig.cmake export_csironn.cmake export_mem-noconfig.cmake export_mem.cmake export_ntk-noconfig.cmake export_ntk.cmake export_null-noconfig.cmake export_null.cmake export_pdf-noconfig.cmake export_pdf.cmake export_plfortrandemolib-noconfig.cmake export_plfortrandemolib.cmake export_plplot-noconfig.cmake export_plplot.cmake export_plplot_octave-noconfig.cmake export_plplot_octave.cmake export_plplot_pyqt5-noconfig.cmake export_plplot_pyqt5.cmake export_plplotada-noconfig.cmake export_plplotada.cmake export_plplotcxx-noconfig.cmake export_plplotcxx.cmake export_plplotdmd-noconfig.cmake export_plplotdmd.cmake export_plplotfortran-noconfig.cmake export_plplotfortran.cmake export_plplotluac-noconfig.cmake export_plplotluac.cmake export_plplotqt-noconfig.cmake export_plplotqt.cmake export_plplottcltk-noconfig.cmake export_plplottcltk.cmake export_plplottcltk_Main-noconfig.cmake export_plplottcltk_Main.cmake export_plplotwxwidgets-noconfig.cmake export_plplotwxwidgets.cmake export_plserver-noconfig.cmake export_plserver.cmake export_pltcl-noconfig.cmake export_pltcl.cmake export_pltek-noconfig.cmake export_pltek.cmake export_ps-noconfig.cmake export_ps.cmake export_psttf-noconfig.cmake export_psttf.cmake export_qsastime-noconfig.cmake export_qsastime.cmake export_qt-noconfig.cmake export_qt.cmake export_svg-noconfig.cmake export_svg.cmake export_tclmatrix-noconfig.cmake export_tclmatrix.cmake export_tk-noconfig.cmake export_tk.cmake export_tkwin-noconfig.cmake export_tkwin.cmake export_wxPLViewer-noconfig.cmake export_wxPLViewer.cmake export_wxwidgets-noconfig.cmake export_wxwidgets.cmake export_xfig-noconfig.cmake export_xfig.cmake export_xwin-noconfig.cmake export_xwin.cmake plplotConfig.cmake plplot_exports.cmake See the detailed commit message for plplot-5.14.0-10-g66d68d93e for the implications of this change for packagers. Once you have added the above export files to the correct binary packages following that advice, you should be able to configure the installed examples project with cmake (with no options) and run make -j$JOBS test_noninteractive without issues just like before (i.e., you will still be subject to the constraint that all binary packages for PLplot have to be installed in order for this to work). To finish off this topic, my next PLplot priority is to follow up with the second upstream change mentioned above which should remove the constraint that all binary packages for PLplot have to be installed in order to test both your binary PLplot packages that are installed, and your package containing the installed examples in the above way. But meanwhile, I hope you are both able to test your binary packages for PLplot and your package containing the installed examples for plplot-5.14.0-10-g66d68d93e in the above way subject to the temporary "all installed" constraint. 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 __________________________ |
|
From: Alan W. I. <Ala...@gm...> - 2019-02-02 09:50:38
|
On 2018-12-18 13:16-0800 Alan W. Irwin wrote: [...] > But meanwhile, I hope you are both able to test your binary packages > for PLplot and your package containing the installed examples for > plplot-5.14.0-10-g66d68d93e in the above way subject to the temporary > "all installed" constraint. @Ole and Orion: I haven't yet made the upstream fix to allow users who have installed only a subset of the PLplot binary packages to test the installed examples. But that fix is still on my near-term agenda (e.g., before the release of 5.15.0 tentatively scheduled for mid-2019). But meanwhile, have either of you made any progress on those requested tests of the "all packages installed case" for the PLplot git master tip version? Such test reports from you would be most helpful since they would verify what I have done upstream up to now. The other purpose of bringing this installed examples test topic up again, is as a recent Debian Buster update (and very likely on Fedora as well) fontconfig has by default started to give the highest preference to the Noto fonts. Most of those are really nice with deserved popularity, but one of them, "Noto Color Emoji" is an old-fashioned pure bitmapped font (likely OK for Emoji's in text but not much else) that has exposed a long-standing issue in libLASi which simply gave up (threw an error and exited) for libLASi-1.1.2 and all prior versions when encountering a pure bitmapped font. The reason for this result is old-fashioned pure bitmapped fonts are completely incompatible with the libLASi library (since it needs scalable outline font information to represent glyphs rather than an old-fashioned bitmap). Of course, this library response to pure bitmapped fonts is much too severe, and the result of this libLASi bug is that PLplot comprehensive tests error out for the psttf and psttfc devices (which depend on libLASi to do the work). This error occurs when PLplot encounters the Aries glyph symbol in example 7 since pango/fontconfig by default chooses "Noto Color Emoji" to render that glyph and ~15 others). So Ole (most likely) and Orion (likely) will run into this libLASi bug when testing the installed PLplot examples unless you either (i) disable both the psttf and psttfc devices or (ii) convince Debian and Fedora packagers to package libLASi-1.1.3. I have just released that new version (see <https://sourceforge.net/p/lasi/news/2019/02/liblasi-113-has-been-released/> which includes my quite important bugfix for the showstopping case when pango/fontconfig decides to use a pure bitmapped font. @Ole: My understanding from <https://packages.debian.org/source/sid/lasi> is Debian packaging efforts for libLASIi are 3 bugfix versions behind (libLASi version 1.1.0 is packaged rather than 1.1.3). I think Debian is in freeze now for the stable release of Debian Buster, but after that is done would you be willing to package libLASi-1.1.3 and do an NMU in response to [Debian bug 921139](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921139). That effort would propagate the important upstream pure bitmapped font bug fix for all Debian and Debian derivative users. @Orion: My understanding from <https://rpmfind.net/linux/rpm2html/search.php?query=libLASi.so.1()(64bit)> is that Fedora packaging of libLASi is only one bugfix version behind (libLASi 1.1.2 is packaged rather than the desired 1.1.3). The Fedora libLASi packager may not have dealt with 1.1.3 yet because the 1.1.3 release is so recent, but if that situation persists I hope you get in touch with him to remind him there is an important upstream bugfix release that should be packaged instead of 1.1.2 to avoid PLplot comprehensive testing errors with the psttf and psttfc devices. @Everybody: there are still some minor PLplot issues for the psttf device driver that Ole and Orion won't face when testing system versions of PLplot. Those issues are the following: * The PLplot build system currently does not configure rpath information for the case when libLASi is installed in a non-system location. To work around this issue I currently set the LD_LIBRARY_PATH environment variable appropriately to help the Linux loader find my locally built and installed version of libLASi. * PLplot currently accepts any version of libLASi. I need to change that so it only accepts libLASi-1.1.3 or above since the prior versions are obviously contaminated with the showstopper pure bitmapped font issue and several other important issues as well that are fixed in libLASi-1.1.3. I hope to deal with both these PLplot issues by early next week. 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 __________________________ |
|
From: Alan W. I. <Ala...@gm...> - 2019-02-02 19:39:58
|
Hi Ole: On 2019-02-02 15:38+0100 Ole Streicher wrote: > Hi Alan, > > > I must confess that I disabled both build time and CI tests for plplot > in Debian, since I could not get them working properly. The main problem > is that the tests don't play well with the way Debian maintains its > Python extensions (especially renaming them). The Python status when we last discussed this is I encouraged your desire to simplify your packaging life by dropping Python2 support in the Debian package since upstream we use Python3 by default, and within a year or so we might drop Python2 completely ourselves. > and I got finally lost in > CMake, where I must admit that I do often not understand what happens. I am pretty good with CMake if I do say so myself. :-) So feel free to ask questions about it here. (I would be willing to answer private questions about CMake as well, but others here might be interested in both your questions and my answers so I prefer you keep this on this mailing list.) > On 02.02.19 10:50, Alan W. Irwin wrote: >> I haven't yet made the upstream fix to allow users who have installed >> only a subset of the PLplot binary packages to test the installed >> examples. But that fix is still on my near-term agenda (e.g., before >> the release of 5.15.0 tentatively scheduled for mid-2019). But >> meanwhile, have either of you made any progress on those requested >> tests of the "all packages installed case" for the PLplot git master >> tip version? Such test reports from you would be most helpful since >> they would verify what I have done upstream up to now. > > > I think this is not a problem anymore, since I now centralized all > examples in the -doc package. Yes, but my goal here is your integrated installed examples package should work regardless of what PLplot binary packages are installed. And I have completed step 1 in that process which was to factor our exported target support into separate configuration files for each of those exported targets. But that change requires work by packagers to make sure that those many different target support files (now interpreted as imported targets) become part of the PLplot binary package containing the executable, library, or dll (device driver) that those (now) imported targets refer to. Once you have completed that packaging work, than the imported targets will exist or not depending on whether the relevant binary packages are installed or not. Note, I have not yet finished the final step 2 in this upstream change which is to make the installed example builds and tests depend on the existence (or not) of the relevant imported targets. But you are in a position now to do the above binary packaging effort and test it so long as you have installed all the relevant binary packages. But as soon as step 2 is completed that caveat will no longer hold and you should be able to also test any combination of installed (or not) binary packages with your examples package. >> [...] So Ole (most likely) and Orion (likely) will >> run into this libLASi bug when testing the installed PLplot examples >> unless you either (i) disable both the psttf >> and psttfc devices or (ii) convince Debian and Fedora packagers to >> package libLASi-1.1.3. I have just released that new version (see >> <https://sourceforge.net/p/lasi/news/2019/02/liblasi-113-has-been-released/> >> >> which includes my quite important bugfix for the showstopping case >> when pango/fontconfig decides to use a pure bitmapped font. > > > I do not really understand what the connection between plplot and lasi > is? Lasi is not a dependency of plplot -- is this wrong? Can you explain > what the relation is? Yes. The psttf device driver (which implements the psttf and psttfc devices) depends directly on libLASi. Which is why this libLASi showstopper bug that is only fixed in libLASi-1.1.3 is so important to PLplot (unless you go out of your way to disable both the psttf and psttfc devices). >> @Ole: My understanding from >> <https://packages.debian.org/source/sid/lasi> is Debian packaging >> efforts for libLASIi are 3 bugfix versions behind (libLASi version >> 1.1.0 is packaged rather than 1.1.3). I think Debian is in freeze now >> for the stable release of Debian Buster, but after that is done would >> you be willing to package libLASi-1.1.3 and do an NMU in response to >> [Debian bug >> 921139](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921139). >> That effort would propagate the important upstream pure bitmapped font >> bug fix for all Debian and Debian derivative users. > > > Lasi is an "orphaned" Debian package, which means that nobody > specifically takes care of it. Only our QA team looks to fix serious > problems. But since the package is rarely used, it may even be removed. > "Someone" should take care of it. BTW, the VCS (on sourceforge) with the > Debian package seems to not work. The libLASi VCS at SF is subversion and is working great here (although resurrecting my knowledge of svn felt a bit strange for a while). But you can try out libLASi for yourself with no need to resurrect your knowledge of subversion or learn about it for the first time. All you need to do is to download the libLASi-1.1.3 tarball and use standard cmake, "make all", ctest, and "make install" to configure, build, test, and install it. Please also look at the project sample at <https://sourceforge.net/projects/lasi/> to see one of the beautiful results that can be generated by this library. (You should also find that beautiful result in examples/ComplexTextLayoutExample.eps and examples/ComplexTextLayoutExample.png in the build tree once you have built the "all" target with make. And you should find a snapshot of that *.png file before you build in the examples subdirectory of the source tree. In sum, it would be a shame to lose this capability for Debian because no maintainer had the time to change the package from 1.1.0 to 1.1.3 (which should be straightforward since the libLASi build system has not changed that much between those versions). And this is not a large commitment because it is a small library that is in deep maintenance mode with a track record of new bug fix releases not occurring that often. So I frankly hope you are interested enough to try libLASi for yourself and follow up with an NMU. But if not, then you should definitely drop the psttf and psttfc devices from your PLplot package. >> @Everybody: there are still some minor PLplot issues for the psttf >> device driver that Ole and Orion won't face when testing >> system versions of PLplot. >> >> Those issues are the following: >> >> * The PLplot build system currently does not configure rpath >> information for the case when libLASi is installed in a non-system >> location. To work around this issue I currently set the >> LD_LIBRARY_PATH environment variable appropriately to help the Linux >> loader find my locally built and installed version of libLASi. > > > In Debian, we would specifically remove RPATH information, since libs > are supposed to be installed in the standard dirs. Yes, that is likely true of all distributions since they use system locations for installed files and for that case RPATH has some downsides with no benefits whatsoever. To accomodate this distribution need we have the option to turn off installed RPATH capability using -DUSE_RPATH=OFF (which I assume your packages are already using). But most individual downloaders install PLplot in non-system locations so they use the default -DUSE_RPATH=ON option because that is the most convenient choice for their use case, i.e., it means they don't have to maintain the LD_LIBRARY_PATH environment variable setting in order to get installed PLplot to work properly. 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 __________________________ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X