Python 3 installation on Linux causes build errors with Python plugin enabled

[peterclemenko]

Having Python 3 installed on Linux will cause the following build errors:

In file included from /usr/include/python3.2mu/Python.h:67:0,
                 from /home/username/dev/rex/naali-deps/install/include/PythonQtInstanceWrapper.h:45,
                 from /home/username/dev/rex/naali-deps/install/include/PythonQt.h:46,
                 from /home/username/dev/rex/naali/src/Application/PythonScriptModule/StableHeaders.h:10,
                 from /home/username/dev/rex/naali/src/Application/PythonScriptModule/PythonScriptModule.cpp:3:
/usr/include/python3.2mu/object.h:402:18: error: expected unqualified-id before ‘;’ token

[jonnenauha]

Please stop making python related issues or at least mark them as feature requests :( We are working hard on actual bugs to get the issue tracker into some kind of shape (we have been over 300 for a long time), these kind of requests are kind of bloating the tracker. Not to mention there are several Python issues already here that would need to be solved for us to get into 3.x support.

We just cleaned most of python issues away and just left one issue for python support being rotten (see #652). Python is not coming back as there is no maintainer or anyone who would need the module, it has been like this for 1-2 years now.

It's known that PythonQt as a library won't build with 3.x and there is probably very little we can do about it if no one is stepping up to the plate.

Sorry for being so blunt but personally I would like to keep the issue tracker clean so its usable also in the future, its already hard to find real issues here with these kind of things laying around.

[peterclemenko]

That's not the underlying issue. Even if you have 2 and 3 both installed, the build script will always try to use 3. This is a flaw in the build process, not a feature request.

Jonne Nauha notifications@github.com wrote:

Please stop making python related issues or at least mark them as feature requests :(

We just cleaned most of them away and just left one issue for python support (see #652). Python is not coming back as there is no maintainer or anyone who would need the module, it has been like this for 1-2 years now.

It's known that PythonQt as a library won't build with 3.x and there is probably very little we can do about it if no one is stepping up to the plate.

---

Reply to this email directly or view it on GitHub: https://github.com/realXtend/naali/issues/663#issuecomment-17771306

Sent from Kaiten Mail. Please excuse my brevity.

[jonnenauha]

Yeah read my edited answer above. My issues with these kind of "bug reports" is that they will never be worked by anyone and you could see that if you would just search "python" in the current issues and read them once. This will be laying here for years to come and I'm probably the only one ever going to comment on this :P

Pyhon stuff in Tundra has been dead for a long long time and imo we should remove (well close) all python related things from the issue tracker as they are not relevant anymore. We could leave the one issue that just summarises "yeah its broken".

[peterclemenko]

Fair enough; this might be worth looking in to though, is it supports 2 and 3: https://qt-project.org/wiki/PySide

[jonnenauha]

I think you have mixed projects a bit :) There is PythonQt http://pythonqt.sourceforge.net/ and PyQt that you linked. We are (were) using PythonQt, I can't recall why we (I guess @antont) did not use PyQt. Nowadays PyQt might be far superior and I remember it had backing from Nokia and the Qt project at some point (Or was it PySide?) cos they wanted something like that for Meego.

Anyhow, PythonQt is a much simpler library it seems but it might have been that it gave us more tools to expose our own QObjects, not just being a Qt wrapper library. At the end of the day we are less interested in Qt itself in scripting than making our Tundra core usable from it. Of course to make core work well Qt must work first.

Edit: Just realized you only meant we should look at the lib PySide, in that you are right if we want to bring python back alive :) Seems like PySide also has Qt5 support that seems nice.

[antont]

Did this come with the new unified build script? I think I have built on systems with also 3 installed and haven't had this, am not sure though. Anyhow a simple version preference or path config build issue, hopefully simple to fix -- hints are welcome, I may look myself too if get a chance.

About use of PythonQt vs PyQt or PySide: the reason was (and is) simply that only PythonQt did what we needed: exposes QObjects with their properties, slots and signals to py. Also PythonQt is made for embedding. PythonQt is basically the same as QtScript but for Py.

PyQt is for making Qt apps in Python (so that the main executable and usually the whole app code is in py) and does not implement the C++ autoexposing at all. PySide inherits the same design and feature scope.

The PythonQt guy actually asked on the PySide list whether they could add the qmetaobject based autoexposing to PySide too, back when PySide was approaching 1.0 or so, but at least back then they responded that it's out of scope for them. Usually when ppl write py qt apps they don't have any custom c++ code so the static exposing of only qt's own c++ classes suffices.

If we move this optional module to a separate repo then ofc issues go there too but I think is fine to resolve this simple build config issue here now.

[jonnenauha]

I think the issue here is not in PythonQt. As you can see he is building Tundra and it originates from PythonScriptModule/PythonScriptModule.cpp.

I guess the real fix for this is here https://github.com/realXtend/naali/blob/tundra2/cmake/ConfigurePackages.cmake#L124 when sagase tries to find Python.h with all those NAMES and COMPONENTS input hints. I'm not sure how its actually finding */python3.2mu path with those, possibly its asking pkg-config or similar linux tool for python and is given that? Maybe the generic python hints should be removed or moved after the more specific python2.6 hints.

Or we check if cmake provides a nicer find(python VERSION 2.6) like it does for Qt etc.

[peterclemenko]

2.7 should also be checked for as well, given that 2.6 isn't in modern distros.

[peterclemenko]

I think this should be moved over to the addons repo.

[peterclemenko]

Moved to the addons repository, closing.