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?

>> The old (plplot-10) Debian package had a build dependency on
>> python-gtk2, a package that does not exist for Python 3. I would
>> suspect that it is not needed anymore?

> [...] So I suspect this build dependency on python-gtk2 is an
> extremely ancient artifact that you can just ignore from now on.

Thank you for the confirmation.

> 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]).

Here, I have the similar objection as above: it duplicates the number of
builds. And combined with the Python triple (for Python-plplot-qt) we
would need to compile the code six times.

Additionally, the number of packages would increase even more. pgplot
currently builds already 27 binary packages. 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. I read the
deprecation message I mentioned in my other mail that they will write RC
bug reports quite soon, so Qt4 packages will not survive for more than a
few months. And the general package restructuring I do in the moment is
a good moment to drop it.

> You have already said that you decided to simplify your life by not
> trying the above approach to support Python2.  But PLplot (after the
> above commit) now works well both for Python2 and Python3, and it
> would be a shame if either Debian Python2 or Python3 users did not
> have access to PLplot. Furthermore, assuming you have since decided to
> support both Python-3.5 and Python-3.6 with two separate builds, then
> adding a third build as above to support Python2 should be
> straightforward for you.  So I hope you decide to go ahead and do
> that. 

Sure; if there is not much effort to support Python 2 aside of all
Python 3 versions, I will not remove the packages.

Best regards

Ole

------------------------------------------------------------------------------
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

Reply via email to