Summary: | dev-lang/python-2.5.2-r7: does not store optimization flags in Makefile | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jakob Schiotz <schiotz> |
Component: | [OLD] Development | Assignee: | Python Gentoo Team <python> |
Status: | RESOLVED UPSTREAM | ||
Severity: | minor | CC: | denilsonsa, flameeyes, frp.bissey |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Jakob Schiotz
2008-10-15 09:41:12 UTC
No, for once a scripting language is doing The Right Thing (tm), both Ruby and Perl get it wrong.... http://blog.flameeyes.eu/2006/05/19/why-it-is-a-bad-idea-to-record-user-settings-during-compile I absolutely agree that the behavior *within portage* is correct: If I change CFLAGS in /etc/make.conf and merge a Python package, it is compiled with the correct flags. I do *NOT* suggest changing that, and if fixing this bug would change that behavior then I prefer this bug! But the problem is that distutils rely on people being able to run "python setup.py install" with zero knowledge about compilers and compiler flags on the current architecture and get a package compiled with reasonable compiler flags, and that is not the case now UNLESS run within an ebuild. (In reply to comment #2) > I absolutely agree that the behavior *within portage* is correct: If I change > CFLAGS in /etc/make.conf and merge a Python package, it is compiled with the > correct flags. I of course meant to write "new flags, which is correct" instead of "correct flags". I sincerely don't see any difference between distutils and autoconf here, in both cases the user is the one who has to override CFLAGS. Sincerely if a _Gentoo_ user is installing something outside Portage I'd expect it to know how to deal with CFLAGS.. (In reply to comment #4) > I sincerely don't see any difference between distutils and autoconf here, in > both cases the user is the one who has to override CFLAGS. > > Sincerely if a _Gentoo_ user is installing something outside Portage I'd expect > it to know how to deal with CFLAGS.. > I have no experience with autoconf, but usually the idea with distutils is that one can just use it and it does the right thing. Of course most gentoo users can figure out to write env CFLAGS='-O2 -march=nocona' python setup.py build especially since the people doing it most are probably those developing the python package. It is just annoying to have to do it - and in particular to have to tell those using the package to do the same thing if they want to install the package under their own account. IMHO, the correct behaviour would be 1. If CFLAGS environment variable is set, use it. 2. If running under portage, use CFLAGS from /etc/make.conf 3. If none of the above, use the CFLAGS from when Python was compiled. The current behaviour is 1. If CFLAGS environment variable is set, use it. 2. If running under portage, use CFLAGS from /etc/make.conf 3. If none of the above, use CFLAGS="-DNDEBUG" ... which means a sloooow code, with the asserts removed. I have been thinking about what it takes to fix this. Probably some kind of patch to distutils is necessary, which runs the risk of introducing other bugs, so unless somebody really knows what they are doing it is presumable best to leave it as it is. Best regards Jakob Current behavior is correct. Re-opening with another proposed behaviour: - leave -DNDEBUG as upstream does, add user flags - add a debug use flag to take -DNDEBUG out. (In reply to comment #7) > Re-opening with another proposed behaviour: > > - leave -DNDEBUG as upstream does, add user flags > - add a debug use flag to take -DNDEBUG out. While I'm personally inclined to state that upstream screwed up here (to the point where pkgcore/snakeoil code actively mangles distutils flags as needed)... they choose it. Not our place to be forcing behaviour noncompliant with the norm. Take the fight upstream please, reopen here if you get traction there. |