From: Alan W. I. <ir...@be...> - 2017-08-29 17:48:50
|
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 __________________________ |