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. _______________________________________________ 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