> On Dec. 14, 2015, 8:24 p.m., Alex Merry wrote: > > Seems sensible to me. Are there any potential Python2 vs Python3 issues?
I don't think there are any -- the `.pyc/.pyo` files are installed with a different name into a different location on Python >= 3.2, but that is already taken care of by the macro. This patch only deals with the path where the `.py` file gets installed, which it does not change. The only problem I see is in the use of the `argparse` module: it does not exist on Python < 2.7, Python 3.0 and Python 3.1. If that's an issue, I can rewrite the code to use `optparse`, which is deprecated but exists on all Python versions, including the deprecated ones. - Raphael ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126345/#review89485 ----------------------------------------------------------- On Dec. 14, 2015, 6:48 p.m., Raphael Kubo da Costa wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126345/ > ----------------------------------------------------------- > > (Updated Dec. 14, 2015, 6:48 p.m.) > > > Review request for Build System, kdelibs and Alex Merry. > > > Repository: kdelibs > > > Description > ------- > > The `PYTHON_INSTALL()` macro is a wrapper around the `py_compile` Python > module that also installs the byte-code (.pyc) file it generates. > > However, when a .py file is passed to `py_compile` without any additional > arguments, its full path is recorded in the .pyc file. This is problematic, > as most distributions install all files into a build root instead of simply > copying files to `/` as part of the packaging process. In this case, the > generated .pyc file will have something like > /wrkdir/buildroot/usr/lib/python2.7/site-packages/Foo/my_module.py > in it. Not only does this show up in exception tracebacks, but if the user > later invokes `my_module.py` and has write access to `my_module`'s directory, > `my_module.pyc` will be rewritten with the right path to `my_module.py` > (without the build root). This can lead to uninstallation errors if the > package management system checks each file before removal, for example. > > Fix it by rewritting the `PythonCompile.py` script so that it takes a > `--destination-dir` argument that we use to pass the full path to > `my_module.py` instead of letting it be (wrongly) deduced. > > > Diffs > ----- > > cmake/modules/PythonCompile.py 156fea2 > cmake/modules/PythonMacros.cmake 6a82d88 > > Diff: https://git.reviewboard.kde.org/r/126345/diff/ > > > Testing > ------- > > Fedora has packaging macros that will regenerate .pyc and .pyo files with the > right paths as part of the build, so it is not affected. Debian disables this > macro in pykde4, FreeBSD and openSUSE contain wrong paths in its .pyc files. > With this patch, I was able to verify with `hexdump` that the right path is > present in the .pyc files installed by pykde4. > > > Thanks, > > Raphael Kubo da Costa > >
_______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem