Re: strawman (Was Re: build systems)

["Gustavo J. A. M. Carneiro" <gjc inescporto pt>]

On Seg, 2007-11-12 at 12:42 +0100, Nicolas Trangez wrote:
> 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.

Yes, it's true. WAF needs some love in the input validation and error
reporting department.  Good news is that it is fixable (as in, does not
take a huge ammount of effort, and waf has a maintainer willing to take
patches, unlike another build system I know of).

> 
> 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.

You have to understand something.  WAF works with build objects which
are defined by a name (object name defaults to the target if not given).
Object names are not hierarchical and have no relationship whatsoever
with the build tree.

  This is a good thing because it allows WAF much more freedom to
schedule object build tasks in parallel, unlike make which can only
parallelize tasks within a single subdirectory.  So, unlike make, waf
-j2 on a dual core processor really uses both processors most of the
time, while make -j2 will often have to wait for a subdir to finish
building before moving on to the next subdir.

Yes, this also means documention could be improved.  But anyway,
autotools also have tons of undocumented quirks; the only difference is
that developers used to autotools have already learned those quirks.

> - 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.

Agreed.  But I think also fixable, since WAF API is not exactly
frozen ;-)

Cheers,

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert