<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">It's always better to improve things than to branch for trivial changes</blockquote>
<div><br>I agree. It's troubling to see this proliferation of project-specific Pyrex branches each with only minor changes.<br><br>In contrast, however, we've been at the mercy of Greg to decide when to accept patches, his available time to rewrite them, then later release, and finally for a new release to be packaged by distros. I understand this is a frustration you guys had too, behind your reason to form Cython, but if we used Cython we would be in the same situation with you than we are with Pyrex.<br>
<br>We're not interested in the language pre-processor politics, we've stayed out of them so far, but given all our logistics we really need greater control over that part of our own project.<br><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
You can't just ignore the most obvious way to build a C extension for Python<br>
(i.e. using distutils), and then come and complain that your hand-written<br>
setup doesn't work.</blockquote><div><br>Oh, we're using Python's distutils to build the C source.<br><br>That 100 lines in our setup.py is a workaround for Pyrex.Distutils failure of detecting source changes and rebuilding .c files only when necessary. That part would be better generalized and in Distutils rather than in our setup.py since any project could take advantage of it<br>
<br>The rest is to generate the list of libraries for distutils to link against. As far as I'm aware this is required for distutils regardless - how's it to know GLEW is called libglew32 on Windows?<br><br><br></div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">improve Cython's distutils helper (build_ext.py) to handle the problem of<br>
calculating dependencies better.</blockquote><div><br>That's what we're looking at, yes. <br><br>I think the most pragmatic solution for us right now is a branch, given our release time table and Cython's level of recent commit activity, and that these changes will undoubtedly require discussion.<br>
<br>We'll of course provide patches.<br></div></div>