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
