I second the part about the C API. We need to be careful we don't lock our API code into python.<br><br>Joe<br><br><div class="gmail_quote">On Fri, Dec 5, 2008 at 9:25 AM, Chris Want <span dir="ltr"><<a href="mailto:cwant@ualberta.ca">cwant@ualberta.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Reading this thread, I become more agreeable to the suggestion<br>
that Early Ehlinger made earlier (no pun intended). He suggested<br>
that python scripting should be handled as an external plugin<br>
that loads at run time. Then the problem of having builds of<br>
blender for different python versions doesn't matter: just<br>
have one blender build and distribute it with plugins for<br>
the different python versions. This, of course, would be a<br>
lot easier with a well thought out C API, which I believe should<br>
be the first step before tackling python (as I've mentioned<br>
before).<br>
<br>
I should also point out that bundling python with blender adds<br>
extra complexity to Blender's plethora of build systems. The<br>
example of FFMPEG is a poor one since not all build<br>
systems support it, there are issues under windowa, the<br>
scons system supports it by having the additional<br>
requirement of having autoconf installed, and I have<br>
recently seen mails on the list from our game engine developer<br>
trying to change the FFMPEG sources in extern, to which<br>
there are no replies from the official maintainer. This is<br>
not a role model to follow.<br>
<br>
Cheers,<br>
<font color="#888888">Chris<br>
</font><div><div></div><div class="Wj3C7c">_______________________________________________<br>
Bf-committers mailing list<br>
<a href="mailto:Bf-committers@blender.org">Bf-committers@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-committers" target="_blank">http://lists.blender.org/mailman/listinfo/bf-committers</a><br>
</div></div></blockquote></div><br>