RetroSearch Browse

Wed Nov 28 00:09:12 CET 2012 · https://mail.python.org/pipermail/python-dev/2012-November/122893.html

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.

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2012-November/122893.html below:

[Python-Dev] Handling support for newer OS features at run time