On Mon, 2007-11-12 at 12:32 +0100, Ali Sabil wrote: > I think we should really investigate WAF Partially agree, if it gets a lot of love. Been working on the clutter port some more, here's some more thoughts: - If you add an include directory which does not exist (eg '../foo' which should be just 'foo'), waf bails out with some completely not-useful message (a Python IndexError?!?), not pointing you to where the mistake could be. Pretty frustrating. - Currently, build just does not work. I have no clue why it doesn't as I get no error messages whatsoever, it doesn't even start a compiler. I start waf and it sits there. Running with -v, -vv or -vvv doesn't give any usable output either. When running it through strace, it first does some open calls etc, then makes hundreds of brk() calls (well, I guess Python does it :-)). No clue what's going wrong. So, it most certainly needs more exception checking and usable error messages if something goes wrong. I fixed the compilation unit separation using shared libraries, I didn't check yet whether they would be installed in the end, as they shouldn't. Need to figure this out (once build works again). There are some "strange" things in waf too: - If you want to include "clutter/pango/clutter-pango.a" in the build of "clutter/libclutter-glx-0.5.0.so", you need to add "clutter-pango" to the obj.uselib_local variable, not "pango/clutter-pango", as I would have expected. - Sometimes Python type usage is rather strange. During configure, conf.env behaves like a dict (conf.env['foo'] = 'bar'), whilst in a build function, bld.env is a function returning something which behaves like a dict (so need to use bld.env()['foo']). Rather confusing. Nicolas
Attachment:
signature.asc
Description: This is a digitally signed message part