At 03:13 PM 3/5/2007 -0500, Christopher Armstrong wrote: >Twisted has a few extension modules that it only wants to build if >certain things are available on the platform - like epoll support if >the epoll.h header file is available, for example. > >We can call a function to run some code to decide which extensions to >build, but in certain cases having access to the compiler object in >distutils would be preferable -- to test certain things about the >platform. Currently we have some fairly heinous hacks to get our code >to run *after* that compiler object is available (i.e., after it's >constructed in build_ext.run), but these hacks are becoming >problematic especially for easy_install support. > >Before showing what these hacks are (if you really care, you can check >the various setup.py files in the Twisted repository), I'd like to ask >if there is any other best-practice knowledge in the community for >conditionally building extensions based on knowledge only available by >using a compiler.
I don't know of any better practices, unfortunately -- certainly nothing that's available portably at the pure distutils level. Setuptools has a primitive "features" system that is used by a few PEAK packages, but it's undocumented and it suffers from a fatal flaw of not noticing that the configuration has changed (and thus requires clean rebuilds). I've thought about adding a "configure" command in 0.7 with some sort of cache facility (and support for wiping out build/ when this information changes). However, the real problem with having any sort of feature/option type stuff in setuptools is how to specify egg platform information. I mean, how many flags can we really put in the filename, after all? :) I'm definitely interested in solving this and related problems, but I have very few ideas about how to do it. _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
