Buggy dependencies handling with multiple ./distribute.sh

[tito]

We should be smarter when using ./distribute.sh.

We should:

• seperate C libs with Python extensions, and prior C libs before any python extensions.
• be smart of the python deps: if someone compiled with -m "kivy" and then "sqlite3 kivy", sqlite3 will be compiled, but not python again. So the module sqlite3 will not appear in the final distribution!

[techtonik]

How about moving from .sh build system to something more Pythonic like SCons?

[knappador]

Mathieu, does this require better usage of distribute.sh or re-design of
part of distribute.sh?

K

2014-05-19 23:47 GMT+09:00 anatoly techtonik notifications@github.com:

How about moving from .sh build system to something more Pythonic like
SCons?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/90#issuecomment-43513261
.

[inclement]

I'll close this as fixed by the new toolchain - it should build a different python-install for each set of optional dependencies.