[Python-Dev] Handling support for newer OS features at run time
Matthias Klose
doko at ubuntu.com
Wed Nov 28 00:09:12 CET 2012
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.
More information about the Python-Dev
mailing list