On Tuesday, 19 September 2006 at 22:38, Dennis Schridde wrote:
> Am Dienstag, 19. September 2006 22:05 schrieb Christian Ohm:
> > I tested waf a bit and it seems to work well. I had some of those "can't
> > link lots of {[]w9r" at the beginning, but that didn't occur later (at
> > the latest with your second version).
> When you run waf with --nocache it doesn't seem to produce those crappy
> LIB_XXX configs. Seems like the caching engine sometimes (randomly?) confuses
> the LIB_...s or LIBPATH_... and stores a whole structure in them. I bet when
> I report that now it will be fixed next week or even tomorrow. ;)
My last tests all worked without --nocache, it just did that at the
beginning.
> That's what I love about waf and Thomas. I told on the mailinglist that the
> current way of configuration confuses me and a week later he had
> reimplemented the whole config (with help and tips from others of course). :)
Sounds good. Our own personal build system maintainer :)
> > Speedwise, my first test was blindingly fast compared to the make build,
> > but that was because '-O2 -g' was missing from the cflags. With those
> > options, both are almost the same speed.
> The build is probably limited by the speed of the compiler.
Yes, mainly. Perhaps on a slower machine you might notice a difference
in build system performance.
> But the configuration is blindingly fast.
Yes, I forgot to mention that.
> > 1. On the first run, waf scans all source files (for dependencies), that
> > takes almost 20 seconds here with no output or indication on what's
> > happening.
> Forgot to tell you about it. Sorry. (And I will tell Thomas that he should
> give a progress info.)
That would be nice, so you actually know what it does (and perhaps
mention that it's a one-time thing; I thought the pause would be there
every time).
> > Oh, and the -p option gives an incentive to eliminate the warnings :)
> When you have a look at the first waf script I sent, then you'll see that the
> warnings don't appear there... He changed it from capturing the stdout/stderr
> to not do it because of bugs in Python when there is lots of output (in this
> case when there are lots of warnings).
They didn't? Can't say I noticed that. Never mind.
--
Talkers are no good doers.
-- William Shakespeare, "Henry VI"
_______________________________________________
Warzone-dev mailing list
[email protected]
https://mail.gna.org/listinfo/warzone-dev
