Build on python3 system #102
Conversation
| find_package(PythonInterp 2) | ||
|
|
||
| #and if that fails use the find program routine | ||
| if(NOT PYTHONINTERP_FOUND) | ||
| find_program(PYTHON_EXECUTABLE NAMES python python2 python2.7 python2.6 python2.5) | ||
| find_program(PYTHON_EXECUTABLE NAMES python python2 python2.7 python2.6 python3) |
There was a problem hiding this comment.
Since our 3.8 branch will drop support for Python 2.6, this could be removed here.
|
In these cases, the parens are syntactically irrelevant in py2. I added the print_function import in the python files not because they were particularly necessary, but because it will now throw an error if someone tries to use the older style print statement. We could add the print_function import into the cmake file snippet but it seems a bit much for a 1-liner. Let me know and I'll update my pull request tomorrow. Thanks for the review. |
|
What I mean, is, will those code fragments in the cmake files get executed when cmake is run on a python2 only system? And if so, will they cause errors? |
|
The 3 changes I made in the .cmake file--putting parens around the print, passing the byte string literal to hashlib, and the floor division operator--are all valid in python 2.7+, but necessary in python 3. The statements will now produce the expected output regardless of python version (within the supported range of 2.7+). $ python -c "from distutils import sysconfig; print(sysconfig.get_python_lib(plat_specific=True, prefix=''))"
lib/python2.7/dist-packages
$ python3 -c "from distutils import sysconfig; print(sysconfig.get_python_lib(plat_specific=True, prefix=''))"
lib/python3/dist-packages
$ python -c "import hashlib; print(hashlib.md5(b'asdf').hexdigest()[:5])"
912ec
$ python3 -c "import hashlib; print(hashlib.md5(b'asdf').hexdigest()[:5])"
912ec
$ python -c "print(5//2)"
2
$ python3 -c "print(5//2)"
2 |
|
Got it, thanks. |
|
I went ahead and merged in to master. This does mean that gnuradio won't be able to use the next master release until next, but that's OK. I'll blow away the master-mako branch. |
This commit introduces two new dependencies: python-mako and python-six. This is based on two facts: * Cheetah templates, used by VOLK_GNSSSDR to generate the library, are deprecated (see https://groups.google.com/forum/#!topic/mako-discuss/1UrwjXnQzxU). The original VOLK is switching to python’s Mako template engine + python-six, and also dropping the Cheetah dependency (see gnuradio/volk#94 and gnuradio/volk#102) * GNU Radio 3.8 will drop python 2.6 support and will be compatible with Python 3. They are possibly dropping out Cheetah templates, too. Since it is still not clear to me what dependencies will pull GNU Radio in version 3.8, and the date it will be released, I think the best way to proceed is to already switch from Cheetah to Mako, and to provide support to Python 3 via python-six. However, while the Cheetah templates were required by GNU Radio =< 3.8 and we knew they were already installed, now the new dependencies python-mako and python-six need to be installed by the user. Instructions in the README files have been updated. In summary: ``` $ sudo apt-get install python-mako python-six ```
This pull request adds support for systems whose default python is python3.
It retains backwards compatibility with Python 2.7.
In a few places, I used "six" to maintain compatibility. This is the same tool that will be required in gnuradio's 3.8 branch to add python3 support.