Re: Switching to Waf instead of SCons?

[John Mandereau]

Le mercredi 16 septembre 2009 à 06:04 +0100, Graham Percival a écrit : 
> Ok.  I'm just worried about re-creating the stepmake mess, where
> Han-Wen and Jan spent a lot of time creating it, but never got it
> merged upstream.  As a result, it's become an evolutionary dead
> end.

This can hardly be the stepmake mess, because Waf is a clearly thought
build system that comes with a full programming language, even if it
mostly has only bare bones, so you have to fight against Waf structure
in order to write messy extensions, whereas GNU Make programming
capabilities are limited to text processing and calling a shell to
program in shell or (often even better) call scripts written in other
languages.  Speaking of, I forgot to mention that in Python code, and
more specifically in wscripts and Waf extensions, process and shell
creations (with pproc.Popen or equivalent) should be avoided whenever an
alternative can be coded in pure Python.


> The more people who use the code, the more bugfixing/examination
> it will get, and the more tutorials and documentations people will
> write.  Granted, I'm thinking about the 3-10 year horizon rather
> than 6-12 months, but I still think it's worth considering.

I hope we can think about a one-year horizon, but you have a point.
Speaking of, has anybody fetched dev/waf branch and tested "waf
configure"? :-)


> > Nope; even if there is a naming clash, we can resolve it in our
> > sources :-)  The only issue I'm scared about is that Waf class
> > interfaces might be a moving target.
> 
> Yes, but if you get it merged upstream, then the class interfaces
> is *their* problem, not *yours*.  :P

This is partially true, because we'll always use the high-level class
interfaces in the wcripts, whereas low-level interfaces should be hidden
in extensions (e.g. our current custom_configure.py) and tools (texinfo,
lilypond, cxx, g++ etc.).  I was afraid of classes interfaces being a
moving target, but from what I have seen Waf developer(s) take(s) great
care to assure backward compatibility at high level.

Best,
John

signature.asc
Description: Ceci est une partie de message numériquement signée