I emerged dev-lang/python-2.4.4-r13 today, and the merge ended with errors during the byte-compilation phase (the merge was successful, though). The last lines of the merge are shown below. Note the lines: * /-x doesn't exist! * /site-packages doesn't exist! * /-x doesn't exist! * /test doesn't exist! which seem to indicate that an extra / is prepended to the arguments to python_mod_optimize in python.eclass. I assume this disables the interpretation of -x as an option to compileall.py. Looking at CVS, it seems that revision 1.36 of python.eclass has introduced this problem, as it treats all arguments as paths and doesn't take options into account. I'm trying to come up with a fix, an will post a patch shortly. Here's the full error from the merge: * Byte compiling python modules for python-2.4 .. ... [ ok ] * /-x doesn't exist! * /site-packages doesn't exist! * /-x doesn't exist! * /test doesn't exist! * Byte compiling python modules for python-2.4 .. ... Compiling /usr/lib/python2.4/test/badsyntax_future3.py ... SyntaxError: ('future feature rested_snopes is not defined',) Compiling /usr/lib/python2.4/test/badsyntax_future4.py ... SyntaxError: ('from __future__ imports must occur at the beginning of the file', ) Compiling /usr/lib/python2.4/test/badsyntax_future5.py ... SyntaxError: ('from __future__ imports must occur at the beginning of the file', ) Compiling /usr/lib/python2.4/test/badsyntax_future6.py ... SyntaxError: ('from __future__ imports must occur at the beginning of the file', ) Compiling /usr/lib/python2.4/test/badsyntax_future7.py ... SyntaxError: ('from __future__ imports must occur at the beginning of the file', ) Compiling /usr/lib/python2.4/test/badsyntax_future8.py ... SyntaxError: ('future statement does not support import *',) Compiling /usr/lib/python2.4/test/badsyntax_future9.py ... SyntaxError: ('not a chance',) Compiling /usr/lib/python2.4/test/badsyntax_nocaret.py ... File "/usr/lib/python2.4/test/badsyntax_nocaret.py", line 2 [x for x in x] = x SyntaxError: can't assign to list comprehension Compiling /usr/lib/python2.4/test/badsyntax_future3.py ... SyntaxError: ('future feature rested_snopes is not defined',) Compiling /usr/lib/python2.4/test/badsyntax_future4.py ... SyntaxError: ('from __future__ imports must occur at the beginning of the file', ) Compiling /usr/lib/python2.4/test/badsyntax_future5.py ... SyntaxError: ('from __future__ imports must occur at the beginning of the file', ) Compiling /usr/lib/python2.4/test/badsyntax_future6.py ... SyntaxError: ('from __future__ imports must occur at the beginning of the file', ) Compiling /usr/lib/python2.4/test/badsyntax_future7.py ... SyntaxError: ('from __future__ imports must occur at the beginning of the file', ) Compiling /usr/lib/python2.4/test/badsyntax_future8.py ... SyntaxError: ('future statement does not support import *',) Compiling /usr/lib/python2.4/test/badsyntax_future9.py ... SyntaxError: ('not a chance',) Compiling /usr/lib/python2.4/test/badsyntax_nocaret.py ... File "/usr/lib/python2.4/test/badsyntax_nocaret.py", line 2 [x for x in x] = x SyntaxError: can't assign to list comprehension [ ok ] * * If you have just upgraded from an older version of python you * will need to run: * * /usr/sbin/python-updater * * This will automatically rebuild all the python dependent modules * to run with python-2.4. * * Your original Python is still installed and can be accessed via * /usr/bin/python2.x. * >>> Regenerating /etc/ld.so.cache... >>> dev-lang/python-2.4.4-r13 merged.
Created attachment 154741 [details, diff] Patch to python.eclass that fixes the problem This patch fixes the problem for me. It parses all options recognized by compileall.py separately, and passes them unchanged.
Ali, I'm adding you as CC, as you seem to be making changes to python.eclass at this very moment.
Looking at compileall.py and python-2.4.4-r13.ebuild, it seems that there is another (related) problem. compileall.py only accepts *one* -x option. If two are specified, the second one replaces the first. However, in python-2.4.4-r13.ebuild (and probably in other ebuilds as well), there are two -x options (-x site-packages -x test). So the site-packages directory is actually recompiled, despite what the ebuild seems to indicate. A fix would be to specify "-x (test|site-packages)" as the -x option takes a regexp, but this will likely not work due to shell quoting issues.
It seems that passing "-x site-packages\|test" instead of "-x site-packages -x test" would work. OTOH, the "site-packages" part could also just be dropped, as it doesn't really take more time to compile site-packages anyway.
Thanks, this should be fixed now. Please reopen if you still have problems.
Sorry for bugging, but you've left in the "for path in $@; do" loop in the "*)" case. The case statement should read: *) [ ! -e "${myroot}/${1}" ] && ewarn "${myroot}/${1} doesn't exist!" [ -d "${myroot}/${1#/}" ] && mydirs="${mydirs} ${myroot}/${1#/}" # Files are passed to python_mod_compile which is ROOT-aware [ -f "${myroot}/${1}" ] && myfiles="${myfiles} ${1}" ;; That is, remove the loop over "$@" and replace all occurrences of "${path" with "${1". Then you don't need the "path" local variable anymore, either. BTW, quoting $2 in the -d|-x case was very elegant!
Ah fail :) Sorry it's too late here and my brain seems to malfunction :-)
Forgot to mention :) It's fixed.
Ali, I'm really sorry to re-open this, but the quoting trick for -x doesn't work. What happens is that the -x argument is passed to compileall.py *including* the quotes, as if you had written the following command line: compileall.py -x \"(site-packages|test)\" /usr/lib/python2.4 The good news is that quoting is not actually needed. In a non-quoted variable expansion, special characters like "(" or "|" are not interpreted specially, only spaces are used to separate arguments. I have tested the following patch, and this time everything works as expected (all directories except site-packages and test are recompiled): --- python.eclass 2008-05-30 00:06:03.000000000 +0200 +++ /root/tmp/python.eclass 2008-05-30 02:15:07.000000000 +0200 @@ -194,8 +194,7 @@ myopts="${myopts} $1" ;; -d|-x) - # -x takes regexp as argument so quoting is necessary. - myopts="${myopts} $1 \"$2\"" + myopts="${myopts} $1 $2" shift ;; -*) I'm really sorry for not having tested the idea before proposing a fix. Next time I'll finish my experiments before suggesting a solution. Thanks for your hard work on Gentoo! It's really appreciated.
First of all, there's no reason to be sorry about reopening bugs. Second, this is fixed now. I've tested it and it works fine. Thanks for reporting :-)
