WIP:Build superkaramba with Python3. #38

Some more work is needed since this solution works only if Python3 is installed with cmake >= 3.12.

If both Python2/3 are installed, cmake defaults to Python3, no ideas of the build actually succeeds (didn't push the test further yet).

This should not be compatible with cmake-2.8.12 either.

Superkaramba lunches, does Python stuff work? => no ideas.

Note: For compatibility with older versions of CMake, you can look for inspiration in tdeedu.

Note: For compatibility with older versions of CMake, you can look for inspiration in tdeedu.

I'm leaning toward a Python3 build exclusive since you've told me that Python3 is been available in Deb/Ubunt for the oldest distros you package.

That being said, cmake2/3 compatibility should still be adressed, to be continued...

I'm leaning toward a Python3 build exclusive since you've told me that Python3 is been available in Deb/Ubunt for the oldest distros you package.

Good idea, also because we will have to move away from python 2 as some point.

As a side note to this PR, I'd like you guys to consider rising minimal cmake version once more (like we did with cmake >= 2.8 to cmake >= 2.8.12)

The oldest version provided by Ubuntu-16.04 is cmake-3.5.1, Debian Etch is cmake-3.7.1, cmake3-3.17.1 is available for Centos7 through EPEL (EPEL stuff is mandatory for rpms btw).

I suggest we rise cmake to 3.5

In this PR the solution works only with cmake >= 3.12, but this is typical kind of thing I have to check each time I work on a cmake conversion.

I have my version of cmake installed from my distrib, once the work is well advanced I have to go online to read the doc for cmake-2.8.12 and check if that version provides the same features (modules search) with the same syntax, sometime I even install cmake-2.8.12 if I'm not sure.
In short, this is extra work and quite annoying.

We had in the past to stick with cmake-2.8 but now we can move on cmake-3.5

Sounds good for me, now that jessie and trusty will no longer be built. Likewise we can also move to c++11 standard, something I am planning to work on early next year.

As for deb packaging, there is currently no obstacle to update the minimum version to 3.5. However, there is no visible benefit at the moment, which would bring it. The mentioned change in Python detection relates to CMake 3.12, so it will still require code supporting CMake versions < 3.12. We can wait for the update until it will bring benefit or it will be necessary?

I guess the ultimate decision is up to you Slavek. I am in favour of the update, but I know where you are coming from and I know it will make more difficult building on older distros if we need it. So final decision is up to you as far as I am concern.

...We can wait for the update until it will bring benefit or it will be necessary?

You know very well that nothing is necessary "per-se" because everything can be done with tweaking and tinkering based on what is already available. It requires more work only...

If there is no drawback moving up, using the last tool is commun sense.

Every new CMake version brings new modules detection or update those available, here is a diff between version 2.8.12 and 3.5:

--- CMakeModules-2.8.12.txt	2021-12-13 10:35:30.448915625 +0100
+++ CMakeModules-3.5.txt	2021-12-13 10:36:20.848917308 +0100
@@ -1,9 +1,12 @@
 CMakeBorlandFindMake.cmake
 CMakeFindBinUtils.cmake
 CMakeFindCodeBlocks.cmake
+CMakeFindDependencyMacro.cmake
 CMakeFindEclipseCDT4.cmake
 CMakeFindFrameworks.cmake
+CMakeFindJavaCommon.cmake
 CMakeFindKDevelop3.cmake
+CMakeFindKate.cmake
 CMakeFindPackageMode.cmake
 CMakeFindWMake.cmake
 CMakeFindXCode.cmake
@@ -13,14 +16,6 @@
 CMakeNMakeFindMake.cmake
 CMakeNinjaFindMake.cmake
 CMakeUnixFindMake.cmake
-CMakeVS10FindMake.cmake
-CMakeVS11FindMake.cmake
-CMakeVS12FindMake.cmake
-CMakeVS6FindMake.cmake
-CMakeVS71FindMake.cmake
-CMakeVS7FindMake.cmake
-CMakeVS8FindMake.cmake
-CMakeVS9FindMake.cmake
 FindALSA.cmake
 FindASPELL.cmake
 FindAVIFile.cmake
@@ -28,6 +23,7 @@
 FindBISON.cmake
 FindBLAS.cmake
 FindBZip2.cmake
+FindBacktrace.cmake
 FindBoost.cmake
 FindBullet.cmake
 FindCABLE.cmake
@@ -55,6 +51,7 @@
 FindGLEW.cmake
 FindGLU.cmake
 FindGLUT.cmake
+FindGSL.cmake
 FindGTK.cmake
 FindGTK2.cmake
 FindGTest.cmake
@@ -66,9 +63,10 @@
 FindHSPELL.cmake
 FindHTMLHelp.cmake
 FindHg.cmake
-FindITK.cmake
+FindIce.cmake
 FindIcotool.cmake
 FindImageMagick.cmake
+FindIntl.cmake
 FindJNI.cmake
 FindJPEG.cmake
 FindJasper.cmake
@@ -81,6 +79,7 @@
 FindLibLZMA.cmake
 FindLibXml2.cmake
 FindLibXslt.cmake
+FindLua.cmake
 FindLua50.cmake
 FindLua51.cmake
 FindMFC.cmake
@@ -90,6 +89,7 @@
 FindMatlab.cmake
 FindMotif.cmake
 FindOpenAL.cmake
+FindOpenCL.cmake
 FindOpenGL.cmake
 FindOpenMP.cmake
 FindOpenSSL.cmake
@@ -131,11 +131,13 @@
 FindTclsh.cmake
 FindThreads.cmake
 FindUnixCommands.cmake
-FindVTK.cmake
 FindWget.cmake
 FindWish.cmake
 FindX11.cmake
+FindXCTest.cmake
 FindXMLRPC.cmake
+FindXalanC.cmake
+FindXercesC.cmake
 FindZLIB.cmake
 Findosg.cmake
 FindosgAnimation.cmake

Here, the new detection for Ice and Intl might come in handy, I also noticed there's a better detection of Ruby (Remember the tinkering to get Ruby's version?).
I don't remember which version, but there's also a better detection with OpenSSL where crypt and SSL are separated, better detection of OpenMP with Clang, etc.

That kind of reasoning could be applied to C++11 too you know; to date, compilers are still compliant with C++98...

>...We can wait for the update until it will bring benefit or it will be necessary? You know very well that nothing is necessary "per-se" because everything can be done with tweaking and tinkering based on what is already available. It requires more work only... If there is no drawback moving up, using the last tool is commun sense. Every new CMake version brings new modules detection or update those available, here is a diff between version 2.8.12 and 3.5: ``` --- CMakeModules-2.8.12.txt 2021-12-13 10:35:30.448915625 +0100 +++ CMakeModules-3.5.txt 2021-12-13 10:36:20.848917308 +0100 @@ -1,9 +1,12 @@ CMakeBorlandFindMake.cmake CMakeFindBinUtils.cmake CMakeFindCodeBlocks.cmake +CMakeFindDependencyMacro.cmake CMakeFindEclipseCDT4.cmake CMakeFindFrameworks.cmake +CMakeFindJavaCommon.cmake CMakeFindKDevelop3.cmake +CMakeFindKate.cmake CMakeFindPackageMode.cmake CMakeFindWMake.cmake CMakeFindXCode.cmake @@ -13,14 +16,6 @@ CMakeNMakeFindMake.cmake CMakeNinjaFindMake.cmake CMakeUnixFindMake.cmake -CMakeVS10FindMake.cmake -CMakeVS11FindMake.cmake -CMakeVS12FindMake.cmake -CMakeVS6FindMake.cmake -CMakeVS71FindMake.cmake -CMakeVS7FindMake.cmake -CMakeVS8FindMake.cmake -CMakeVS9FindMake.cmake FindALSA.cmake FindASPELL.cmake FindAVIFile.cmake @@ -28,6 +23,7 @@ FindBISON.cmake FindBLAS.cmake FindBZip2.cmake +FindBacktrace.cmake FindBoost.cmake FindBullet.cmake FindCABLE.cmake @@ -55,6 +51,7 @@ FindGLEW.cmake FindGLU.cmake FindGLUT.cmake +FindGSL.cmake FindGTK.cmake FindGTK2.cmake FindGTest.cmake @@ -66,9 +63,10 @@ FindHSPELL.cmake FindHTMLHelp.cmake FindHg.cmake -FindITK.cmake +FindIce.cmake FindIcotool.cmake FindImageMagick.cmake +FindIntl.cmake FindJNI.cmake FindJPEG.cmake FindJasper.cmake @@ -81,6 +79,7 @@ FindLibLZMA.cmake FindLibXml2.cmake FindLibXslt.cmake +FindLua.cmake FindLua50.cmake FindLua51.cmake FindMFC.cmake @@ -90,6 +89,7 @@ FindMatlab.cmake FindMotif.cmake FindOpenAL.cmake +FindOpenCL.cmake FindOpenGL.cmake FindOpenMP.cmake FindOpenSSL.cmake @@ -131,11 +131,13 @@ FindTclsh.cmake FindThreads.cmake FindUnixCommands.cmake -FindVTK.cmake FindWget.cmake FindWish.cmake FindX11.cmake +FindXCTest.cmake FindXMLRPC.cmake +FindXalanC.cmake +FindXercesC.cmake FindZLIB.cmake Findosg.cmake FindosgAnimation.cmake ``` Here, the new detection for Ice and Intl might come in handy, I also noticed there's a better detection of Ruby (Remember the tinkering to get Ruby's version?). I don't remember which version, but there's also a better detection with OpenSSL where crypt and SSL are separated, better detection of OpenMP with Clang, etc. That kind of reasoning could be applied to C++11 too you know; to date, compilers are still compliant with C++98...

Making Python3 the default build for SuperKaramba involes looking for compatibility between Python2 and Python3, testing applets and/or themes but I don't wish to spend so much time on this testing and search so I'm closing this PR.

...We can wait for the update until it will bring benefit or it will be necessary?

You know very well that nothing is necessary "per-se" because everything can be done with tweaking and tinkering based on what is already available. It requires more work only...

If there is no drawback moving up, using the last tool is commun sense.

Every new CMake version brings new modules detection or update those available, here is a diff between version 2.8.12 and 3.5:
.
.
.
Here, the new detection for Ice and Intl might come in handy, I also noticed there's a better detection of Ruby (Remember the tinkering to get Ruby's version?).
I don't remember which version, but there's also a better detection with OpenSSL where crypt and SSL are separated, better detection of OpenMP with Clang, etc.

That kind of reasoning could be applied to C++11 too you know; to date, compilers are still compliant with C++98...

Great, the list of new modules was very useful, it's a good stimulus, thank you!