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

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

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
__________________________