On Thursday, 28 September 2006 at 19:39, Dennis Schridde wrote:
> Am Donnerstag, 28. September 2006 17:57 schrieb Christian Ohm:
> > - A (hopefully attached) patch for waf so the patch to Warzone isn't
> > needed anymore.
> The patch should not be needed.
> Instead you should set conf.env['EXT_BISON_H'] = '.h'
But you can't override the bison_str in the wscript, can you? Without
that, waf doesn't find the files.
(After an svn up for waf):
OK, the bison_str now includes -o, so overriding the variables in the
wscript should be enough.
(Very nice to have your own private build system developer ;)
> But this is currently broken for Bison. :(
> (Flex works, but we don't need it. *grml*)
> I think I told Thomas some time ago, but apparently he forgot.
> I just filed in a BR.
>
> > - Speed seems better than before.
> > - 0.9.1: 1:17
> > - current svn: 1:07
> > - make: 0:57
> > I guess the make build is faster because of different options to gcc,
> > though I tried to use the same. Or perhaps something else in the
> > wscript file. On my last test, waf and make were roughly the same
> > speed.
> Is that when compiling? Or with allready built targets?
Complete recompile including the dependency checking (contrary to the
last time - so dependency checking got about twice as fast on my machine
since 0.9.1). The current SVN does it not at the beginning but
interspersed with compilation, so I missed that.
> > - Sometimes there's some kind of deadlock when using -j3 (I haven't
> > noticed it without yet, but I usually use -j3), the last file shown
> > is src/aiexperience.c. Then waf hangs and even ctrl-C doesn't end it,
> > I have to use ctrl-\ to kill waf. I guess I have to investigate that
> > further if it's not a know problem. (Using the current svn waf)
> I didn't try -j3 yet. I'll do that in the future.
Very useful for an SMP machine - without that, the complete build takes
2:00 minutes instead of 1:07 here.
I think I got something here... hangs at aiexperience.c again (-j2 this
time), with no other error message, the traceback occurred a few files
before aiexperience.c (which, incidentally, is the last file to be
compiled), I guess with -j3 it was even farther up so I didn't see it:
Exception in thread Thread-1:
Traceback (most recent call last):
File "threading.py", line 442, in __bootstrap
self.run()
File "/home/co/.waf-0.9.3/wafadmin/Runner.py", line 355, in run
ret = proc.run()
File "/home/co/.waf-0.9.3/wafadmin/Task.py", line 283, in run
return self.m_action.run(self)
File "/home/co/.waf-0.9.3/wafadmin/Action.py", line 54, in run
return self.m_function_to_run(task)
File "<string>", line 17, in f
File "/home/co/.waf-0.9.3/wafadmin/Runner.py", line 98, in
exec_command_interact
stat = proc.wait()
File "/home/co/.waf-0.9.3/wafadmin/pproc.py", line 544, in wait
pid, sts = os.waitpid(self.pid, 0)
OSError: [Errno 10] No child processes
> > - The working of the waf script is a bit tricky: It carries the
> > wafadmin directory attached to it, and puts that into ~/.waf-x.y.z,
> > but only if this directory doesn't exist yet. So when modifying it
> > you have to delete ~/.waf-x.y.z first, else you get the old version
> > and thus the modifications are not used.
> That's intended.
> You can export WAFDIR to /waf/svn/version/wafadmin or use ./waf --nocache
Hm, OK... but it's a bit counterintuitive having the single waf script
which effectively is not used if there's an older version in
~/.waf-x.y.z... Imagine we strip waf of some unneeded stuff like OCAML,
and someone uses the same waf version in another project and needs it.
Then waf will break in a totally opaque way.
> > - Is there an easy way to use several build directories with different
> > compiler settings? With the autostuff I can do for example:
> > mkdir debug; cd debug
> > ../configure --enable-debug
> > make
> > cd ..
> > mkdir release; cd release
> > ../configure
> > make
> > mkdir cpp; cd cpp
> > ../configure CC="g++ -fpermissive"
> > make
> > and I can build a debug version, a release version and test g++
> > compilation, all from the same source tree. Is that possible with
> > waf? It seems blddir is defined in wscript without a way to override
> > it.
> The intention of the author was not to change the builddir.
> Instead you should use variants. Have a look at the build and configure
> functions of the attached wscript.
> Thomas proposed an easier way to handle variants as soon as he has an
> overview
> of how developers expect them to behave.
Hmm... the big difference I see here is: The waf variants have to be
defined in the wscript, while the autostuff can have any number of
different configurations just by running ./configure in a different
directory. I really came to like that feature of autoconf, that's the
only thing I really miss in waf right now.
--
Nothing shortens a journey so pleasantly as an account of misfortunes at
which the hearer is permitted to laugh.
-- Quentin Crisp
_______________________________________________
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
