Am 28.11.2012 06:37, schrieb Gregory P. Smith: > On Tue, Nov 27, 2012 at 3:19 PM, Trent Nelson <tr...@snakebite.org> wrote: > >> On Tue, Nov 27, 2012 at 03:09:12PM -0800, Matthias Klose wrote: >>> Am 27.11.2012 23:49, schrieb Trent Nelson: >>>> I don't think we've currently got the ability to do this, right? >>>> Is there a precedent set anywhere else? I suspect it's not as >>>> much of an issue on *NIX platforms as you'll typically compile >>>> from source. Windows, not so much. >>>> >>>> Thoughts? A single binary that dynamically loads applicable >>>> modules seems cleaner but will obviously take more work. Other >>>> approach would be to start distributing multiple versions of >>>> Python based on the underlying Windows version. Not the nicest >>>> approach. >>> >>> Usually I have to build a python package on a build daemon running the >>> kernel of the latest stable (or latest stable long term support) >>> release. Thus if a configure test checks the current kernel, then you >>> may get an unexpected answer and a missing feature. It is somehow >>> different that I already build different binaries (per release), but >>> the hard-coding of kernel features during configure time looks like >>> the same issue. Currently working around it by patching configure to >>> remove the test and hard-code it for a particular build. Another >>> solution maybe would to have something like --enable-kernel=<version> >>> (as found in glibc), and hope that you can deduce the features from >>> the kernel version. >> >> Hmmm. How often do Linux kernel versions expose new features that >> we can make use of in Python? i.e. do you run into this problem >> often? Can you cite some recent examples? >> > > Here's an example of using the pipe2() system call. The code is only > compiled in if the C library supports it. If the C library supports it, the > system call can still return an error because the running kernel doesn't > support it (ENOSYS). In that case it falls back to the legacy code: > > > http://hg.python.org/cpython/file/618ea5612e83/Modules/_posixsubprocess.c#l738
another one is the check for working semaphores for the multiprocessing module, seen at https://launchpad.net/bugs/630511 _______________________________________________ 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
