On Wed, Jan 20, 2010 at 5:27 PM, Collin Winter <collinwin...@google.com> wrote: [big snip] > In order to support hardware and software platforms where LLVM's JIT does not > work, Unladen Swallow provides a ``./configure --without-llvm`` option. This > flag carves out any part of Unladen Swallow that depends on LLVM, yielding a > Python binary that works and passes its tests, but has no performance > advantages. This configuration is recommended for hardware unsupported by > LLVM, > or systems that care more about memory usage than performance.
Does disabling the LLVM change binary compatibility between modules targeted at the same version? At tonight's Boston PIG we had some binary package maintainers but most people (including myself) only cared about source compatibility. I assume linux distros care about binary compatibility _a lot_. [snip] > Managing LLVM Releases, C++ API Changes > --------------------------------------- > LLVM is released regularly every six months. This means that LLVM may be > released two or three times during the course of development of a CPython 3.x > release. Each LLVM release brings newer and more powerful optimizations, > improved platform support and more sophisticated code generation. I don't think this will be a problem in practice as long as the current rules hold - namely that if someone has already committed a patch that patch wins unless the later commit is clearly better. That puts the onus on people working out-of-sight to incorporate the public mainline. I'm sure many internal googler's (and Ubuntu'ers, and whomever's) patches have already been developed on that timeline and were integrated into the core without remark or incident. [snip] > Open Issues > =========== > > - *Code review policy for the ``py3k-jit`` branch.* How does the CPython > community want us to procede with respect to checkins on the ``py3k-jit`` > branch? Pre-commit reviews? Post-commit reviews? > > Unladen Swallow has enforced pre-commit reviews in our trunk, but we realize > this may lead to long review/checkin cycles in a purely-volunteer > organization. We would like a non-Google-affiliated member of the CPython > development team to review our work for correctness and compatibility, but we > realize this may not be possible for every commit. As above, I don't think this will be a problem in practice -- how often do two people work on the same part of the core? So long as the current "firstest with with mostest" practice holds for public commits it doesn't matter what googlers do in private. I like it, -Jack _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
