On Mon, 2007-11-12 at 13:43 +0000, Gustavo J. A. M. Carneiro wrote:
> 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.
Then there need to be several extra checks. The cause of all the brk
calls reported earlier (which made waf go nuts) was this: I had one
('cc', 'objects') in clutter/clutter/glx which I called clutter-glx, and
the final ('cc', 'shlib') in clutter/clutter which should have become
libclutter-glx.so in that time, so it was also target clutter-glx. This,
obviously, resulted in some infinite loop style case, which was not
detected by waf, and it took quite a while before I figured out this was
the cause.
Anyway, I do not see any reason why adding path information to the
"name" of objects would change anything related to parallelizing the
build: if now I use "foo" and "bar" for 2 objects, what would be the
difference when using "a/foo" and "b/bar"? It'd make it imho much easier
to refer to objects ("Damn, I know this must be foo, but what target did
I call foo?") and reduce naming collision chances.
Nicolas -- made his first waf patch today, adding glib-mkenums
support :-)
Attachment:
signature.asc
Description: This is a digitally signed message part