6:19 a.m.
Hi,
it took a while... after trying to grasp "the big picture", I came up
with these:
https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic...
The old topic:
https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic...
was rebased (not yet 100%) on top of 'build-system-overhaul'.
I've tried to implement a solution, that would clean up our
configure.ac/Makefiles, make Python 3 packaging possible, make running
tests with multiple interpreter versions possible for the developers, etc.
I know, that I will get "crazy looks" for writing m4 macros, but I
really believe having stuff like 'VDSM_PY_SUPPORTED_MAJOR_VERSION' et
al. will make developers' lives easier.
I'm currently trying to address issues and comments raised by Milan, I
would definitely like to get others opinions on these.
Regards, Marcin
On 3/4/19 3:46 PM, Marcin Sobczyk wrote:
> On 3/1/19 2:39 PM, Milan Zamazal wrote:
>> Marcin Sobczyk <msobczyk(a)redhat.com> writes:
>>
>>> I've posted a series of patches:
>>>
https://gerrit.ovirt.org/#/q/topic:py3-rpm-packages+(status:open+OR+statu...
>>>
>>>
>>> They do a couple of things:
>>>
>>> * add an '--enable-python3-build' argument to 'autogen.sh'
>>> * modify 'Makefile.am' so it uses either 'vdsm.spec.in' or
>>> 'vdsm-py3.spec.in' file to build RPMs
>>> * preserve the 'vdsm.spec[.in]' filename in dist archives for both
>>> py2
>>> and py3 packaging
>>> * fix shebang lines in a dist-hook, so that py3 packages will contain
>>> only '#!/usr/bin/python3' shebangs
>>> * prepare the CI for building py3 packages on fc28
>> Hi Marcin, cool, thank you!
>>
>>> So actually, if we replace the dummy 'vdsm-py3.spec.in' file in
>>> https://gerrit.ovirt.org/#/c/98119/ with something useful (be it the
>>> nasty, hacky one, or the shiny, new one), we're ready to build py3
>>> packages.
>> I've made a dirty one: https://gerrit.ovirt.org/98150 (you can simply
>> cherry pick the to wherever you need).
>>
>> However, it doesn't work, it's still built with Python 2 on my Fedora
>> 28. I can see a lot of warning such as
>>
>> DEPRECATION WARNING: python2 invoked with /usr/bin/python.
>> Use /usr/bin/python3 or /usr/bin/python2
>> /usr/bin/python will be removed or switched to Python 3 in the
>> future.
>>
>> I can see that configure.ac in your patches still uses Python 2. Here
>> is what I used in my private hacks to change that. Something similar
>> should be done, depending on --enable-python3-build presence, and with
>> properly detected Python versions.
>
> Good point - I'm currently working on resolving that. It got kinda
> complicated but will keep you posted as soon as I get some results.
>
>>
>> Would you like to make the necessary changes or should I make them
>> myself?
>>
>> modified configure.ac
>> @@ -48,7 +48,7 @@ AM_INIT_AUTOMAKE([-Wno-portability])
>> # Checking for build tools
>> AC_PROG_LN_S
>> -AM_PATH_PYTHON([2.6])
>> +AM_PATH_PYTHON([3.6])
>> AC_ARG_ENABLE(
>> [hooks],
>> @@ -349,13 +349,13 @@ if test "$PYTHON3_SUPPORT" = "1"; then
>> fi
>> # Checking for python-devel
>> -AC_PATH_PROG([PYTHON_CONFIG], [python-config])
>> +AC_PATH_PROG([PYTHON_CONFIG], [python3-config])
>> if test "x$PYTHON_CONFIG" = "x"; then
>> - AC_MSG_ERROR([python-devel not found, please install it.])
>> + AC_MSG_ERROR([python3-devel not found, please install it.])
>> fi
>> # Checking for python modules (sorted, please keep in order)
>> -AX_PYTHON_MODULE([six], [fatal], python2)
>> +AX_PYTHON_MODULE([six], [fatal], python3)
>> # External programs (sorted, please keep in order)
>> AC_PATH_PROG([CAT_PATH], [cat], [/bin/cat])