On 2017-08-29 11:44+0200 Ole Streicher wrote:
Hi Alan,
On 28.08.2017 00:13, Alan W. Irwin wrote:
On 2017-08-27 11:00+0200 Ole Streicher wrote:
One point there however remains: I need to support all Python 3
versions we have in Debian; currently Python 3.5 and Python 3.6.
The difference are just the shared library stubs, which are
compiled using the specific header files (the package will contain
both shared libs). Do you have an idea how I could simply do this?
Use multiple builds.
Also to make this easier for you I have now (commit e320210) improved
user control of the Python version.
So for one build you specify -DPLPLOT_PYTHON_EXACT_VERSION=3.5.0 and
for the other you specify -DPLPLOT_PYTHON_EXACT_VERSION=3.6.0, and it
should "just work" according to my tests of the above commit.
Thank you for this; I am however still unsure: Multiple builds would
mean to (currently) triple the whole build process (2.7, 3.5, 3.6),
right? Or can I build the Python binding individually?
Mostly individually. For example, if you used the cmake parameters
(-DFORCE_PYTHON2=ON -DDEFAULT_NO_DEVICES=ON -DPLD_extqt=ON
-DDEFAULT_NO_BINDINGS=ON -DENABLE_python=ON -DENABLE_qt=ON
-DENABLE_pyqt5=ON) to configure a build and install of just the
minimum PLplot components you need to support both python and pyqt5
under Python2, then that means there is a large saving in build cost
since few devices are built and few bindings are built. Of course,
there is some duplication of build effort here, but it is tiny (just
the duplicate rebuild of the plplot C library and its small C library
dependencies, i.e., csironn, csirocsa, and qsastime) relative to what
a full PLplot build costs.
Our Qt-related components work extremely well with Qt4, and also
work pretty well (aside from small character alignment issues and a
segfault for pyqt5) with the Debian Jessie version of Qt5. But those
Qt5 issues are bound to go away as that library matures (and in fact
may have gone away already with the later versions of Qt5 that you
have access to with later Debian versions). But I also don't think
you should throw away our superb Qt4 capabilities prematurely. So I
suggest you use a multiple build approach here as well (one with
-DPLPLOT_USE_QT5=ON and one with the default value of that option
[-DPLPLOT_USE_QT5=OFF]).
[...]
If we would split by the Qt
version we would have:
plplot-driver-qt4, plplot-driver-qt5,
libplplotqt4-2, libplplotqt5-2,
python-plplot-qt4, python-plplot-qt5,
python3-plplot-qt4, python3-plplot-qt5
so four more packages. For a library that is deprecated, this sounds a
bit overkill, especially for a soon-to-be-removed package.
Having finally read the reference you gave concerning how soon Qt4 is
going to be removed from Debian, I now agree building Qt4-related
components of PLplot would be overkill (although the multiple build
cost would have been low since as in the python case above there is a
way to pare down the Plplot build to just the bare essentials
concerning its Qt-related components).
To summarize, I think you should do multiple builds for python 2.7,
3.5, and 3.6 (with relatively small extra build cost), but I agree you
should stick strictly to Qt5 for our Qt-related components because Qt4
is about to be removed from Debian.
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
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
__________________________
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
