Eli Collins <e...@assurancetechnologies.com> added the comment: > What would the value be for non-C Python implementations?
I'm not really sure how this idea could have any value for those implementations, at least for the ones that can't make use of C extensions at all (I think PyPy can; so I guess that would leave Jython & IronPython). Then again, I don't see how anything inside "disutils2.compiler" could be relevant to those implementations either, so maybe I don't understand the question. > If the need for compiler-specific options is very common, we could > consider either improving the compiler system or implement this > request; if it’s not common, letting people use hooks would be enough. I'm not entirely sure how common this is; even within those people who write C extensions, but I'm pretty sure some problems are unavoidable, such as compiler-specific options when linking to external libraries or compiler-specific ways of specifying compatibility options. Case in point: this stackoverflow question ( http://stackoverflow.com/questions/724664/python-distutils-how-to-get-a-compiler-that-is-going-to-be-used ) had a few solutions... and it seems to me that the cleanest one (from 'Jon') made much more sense as an environment marker. A similar case is this email thread ( http://comments.gmane.org/gmane.comp.python.devel/123768 ), which presents a situation where the person needs to set different options for a specific *version* of a compiler. In that case, the main solution people proposed was "see if setup() fails, and try again with different options". This is the same solution SQLAlchemy & SimpleJson have been using to implement "optional" c extensions under distutils1; and I wasn't sure if hacks like that were even going to be possible using the new hooks system. Mind you, the person in that email thread needed to distinguish different *versions* of particular compilers, which I didn't propose in this issue - mainly because the compilers already have unique names assigned to them, and would only require making that info available; whereas gathering version strings and comparing them would require much more work & testing to implement properly. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12242> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
