Re: [Plplot-devel] plplot-5.14.0 has been released

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

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

> Hi Alan,
>
> "Alan W. Irwin" <Ala...@gm...> 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
__________________________