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?
I'm not sure how much could be shared between Windows and Linux with
what you've just described. With Windows, specifically with regards
to providing dynamic select.poll() support, I was thinking of having
multiple modules:
Python33\
DLLs\
select.pyd
select_win6.pyd
select_win7.pyd
select_win8.pyd
And Python would automatically import the appropriate one. I don't
think this would be that useful on Linux -- as you say, the decision
is typically made at ./configure time.
Trent.
_______________________________________________
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
