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

[Alan W. Irwin]

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//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_" signature for all
library and shared object installs, and for each of those I add a

install(EXPORT export_ DESTINATION ${LIB_DIR}/cmake/plplot 
NAMESPACE ${PROJECT_NAMESPACE})

The net result will be two files per target installed with names

export_.cmake and export_-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_.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_.cmake and
export_-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 

Re: [Plplot-devel] 5.14.0 release status

[Alan W. Irwin]

The PLplot development freeze that started on October 27th contines, i.e.,
do not push any topics other than documentation updates or well-tested bug
fixes.

I am sorry to report that my pace for getting this release out has
frankly slowed to a crawl, but there is some hope I will be able
to restore a normal pace soon.

The reason for this delay is I have been distracted in the last week
by researching a chance to finally work around random lockups I have
been encountering for my new Ryzen 7 1700 Linux box since I bought it
in May.  (For background information about Ryzen instability problems
caused by a fundamentel AMD Ryzen hardware design flaw see
 and
.)  Those links
state one possible workaround requires building a specially configured
custom Linux kernel.  I finally managed to do that today after many
false starts, and I am running that custom kernel now.  And with luck
perhaps this lockup distraction will be considerably reduced or even
eliminated by this custom kernel.

In sum, time will tell, and in any case I will continue to keep you
informed about how the plplot-5.14.0 release process is going with status 
reports
like this one every week or so.

Alan
__
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__


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