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
_______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
