On 2018-12-12 16:33+0100 Ole Streicher wrote:

Hi Alan,

"Alan W. Irwin" <alan.w.irwin1...@gmail.com> writes:
A comprehensive test and some additional specific tests of my fix for the
release critical bug went well, and as a result I have now released
5.14.0.  See my forthcoming post to plplot-general for the details
concerning that release.

thank you very much for preparing the new release! And congratulations
for the success!

You are welcome.


I am now preparing the Debian package, and for there, I have a few
questions:

* the soname (ABI version) of libplplot changed to 16, right? Any other
 soname changes?

Yes.  Here is the transformed git diff results on soname changes:

software@merlin> git diff 5cac57603d^ 5cac57603d cmake |grep '^[+-]set' |grep 
'SOVERSION ' |sort --key=1.2
-set(plplot_SOVERSION 15)
+set(plplot_SOVERSION 16)
-set(plplotada_SOVERSION 2)
+set(plplotada_SOVERSION 4)
-set(plplotcxx_SOVERSION 13)
+set(plplotcxx_SOVERSION 14)
-set(plplotdmd_SOVERSION 3)
+set(plplotdmd_SOVERSION 4)
-set(plplottcltk_SOVERSION 13)
+set(plplottcltk_SOVERSION 14)

I plan to put some variant of this command in README.Release_Manager_Cookbook 
for
next time since it makes obvious any typograpical errors in the library version 
updates
such as incrementing plplotada_SOVERSION by 2 rather than 1, above.  Sigh...


* Is it now possible to build for more than one Python version? In
 Debian, we would need to build it for all available Python 3 versions
 (Python 3.6 and 3.7 in the moment), it would be nice if that would be
 supported directly. Same is for the pyqt5 driver.

Sorry, we don't have direct support for building against multiple soft 
dependencies.
So to provide this capability I assume you have some combination of multiple 
builds for multiple
Python 3 versions.  But for the second and subsequent builds you can eliminate 
most
of the repeated stuff that you don't need to make the multiple builds quite 
efficient.

For example, if you use the CMake options

-DDEFAULT_NO_BINDINGS=ON -DENABLE_python -DENABLE_pyqt5 -DDEFAULT_NO_DEVICES=ON

you will end up not building any devices and no bindings other than python and 
pyqt5.  So
the only redundant builds left should be the small libraries in the lib 
directory
and the core C library itself that depends on those.

* Given that Python 2 will die in 16 months, do you object when removing
 the Python 2 (python-plplot and python-plplot-qt) packages?

A year or more ago I had direct advice from a Python developer that
bugs in Python 2 (i.e., a corruption I discovered back then in one of
my Python2-generated *.pyc files that was due to a Python2 race
condition) are rarely fixed any more.  So I haven't deprecated our
Python 2 capabilities yet, but it is "on my radar", and if you choose
to remove those capabilities for your Debian packages that is fine
with me.

[...]
When I try to run the build time test, I get an error:

------------------------8<-----------------------------
ctest  --extra-verbose
UpdateCTestConfiguration  from :/build/plplot-5.14.0+dfsg/DartConfiguration.tcl
UpdateCTestConfiguration  from :/build/plplot-5.14.0+dfsg/DartConfiguration.tcl
Test project /build/plplot-5.14.0+dfsg
Constructing a list of tests
Updating test list for fixtures
Added 0 tests to meet fixture requirements
Checking test dependency graph...
Checking test dependency graph end
No tests were found!!!
/usr/bin/make -C obj-* VERBOSE=1 test_diff_psc
make[2]: Entering directory '/build/plplot-5.14.0+dfsg/obj-x86_64-linux-gnu'
make[2]: *** No rule to make target 'test_diff_psc'.  Stop.
------------------------8<-----------------------------

Should I do now something different than

$ ctest  --extra-verbose
$ make -C obj-* VERBOSE=1 test_diff_psc

You have to build the "all" target before you run ctest.  Otherwise, you will 
get
no tests as above.

I have never tried the -C option to make, but apparently it is a way to
short-circuit recursive invocations of make.  But I doubt that idea is robust
for all versions of cmake, and therefore I suggest you just drop
that option.  After all, running

make VERBOSE=1 test_diff_psc

is already quite fast and the time difference between using the -C option (when 
it works)
versus not has got to be negligible since that time is dominated by running all 
the C examples
for the psc device.

By the way, why are you building individual low-level test targets such as 
test_diff_psc?  Wouldn't it
be much more efficient to, say, build all low-level noninteractive tests in 
parallel, with, say
(assuming you have access to a computer with 16 threads)

make -j16 VERBOSE=1 test_noninteractive

?

Right now, when I do that here, I am getting time results equivalent to 4.5 
threads, but
other compilation-only tests I have done show that efficiency statistic can 
rise to the equivalent
of about 15 threads (on my Ryzen 7 1700 system with 8 cpus and 16 hardware 
threads).  So
I think the reduced parallel efficiency of test_noninteractive is because those 
jobs
are generating so many files, i.e., the task is i/o dominated rather than 
cpu-dominated.
However, I have plans to try it out with an SSD (which should have much quicker 
i/o),
and it will be interesting in that case if I can get the equivalent thread 
number
up near 16 as well.

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

Reply via email to