W dniu 8 stycznia 2010 17:58 użytkownik Michal Suchanek <hramrach@...704...> napisał: Here are some of them. 1. No need to list every source file in scripts, since one can use globbing.* 2. Build scripts are written in Python and can use the full power of a general programming language. This is immensely important once you start to do non-standard things during the build. 3. On Windows it does not require emulation layers or shell replacements like Cygwin or MSYS. 4. Good support for parallel builds, even when the sources and build scripts are in multiple directories. 5. Can replace the current btool + automake combo, so we finally have one build system for all platforms. (This is actually the main reason.) 6. It takes about 100 kB, so it can be bundled with the source tarball. We can ship a version tweaked to our liking, for example without tool modules we don't use or with extra features. (That's what I do now, I use r6828 of waf-1.6 branch, though perhaps I could tweak the scripts to work with waf 1.5) 7. It is easy to include generated .cpp code as the source of an executable or library (once you figure out the correct way - the docs are useless). 8. Everything created by the build system is kept in the "build" directory (the name can be changed), so distclean is as simple as deleting "build". There are also some downsides. 1. I do not understand the maintainer's development philosophy. For example I refactored a portion of the function job_count() that retrieved the number of CPUs into a new function cpu_count(). He merged it back into job_count() and added a somewhat arbitrary limit of 1024 simultaneous jobs. Then there was an "ordered dictionary" that stored the insertion order in a list. When adding a key, it searched the list rather than the dictionary to see whether the key exists. He declined to change it to search in the dictionary, because it was an "unnecessary optimization". He also said that "the list will never reach 1000 elements". 2. Since the maintainer started working on the waf-1.6 branch, he does not keep it in a working state, but rather uses the SVN repository like remote storage for his experiments. Not to mention the fact that he uses the trunk for the stable version and the waf-1.6 branch for new development. 3. The API docs are non-existent. The only existing piece of documentation, the "Waf book", is in large part irrelevant to the end user and non-free (CC with no derivative works clause). When asked about why it's non-free and others can't improve it, the maintainer said it's to prevent distributions from shipping a system-wide Waf package, which is discouraged. This reason is bogus because there is a Waf package in Debian that simply doesn't include the non-free book. 4. Certain parts of the code rely on Python-specific tricks like replacing methods in classes or compiling code at runtime, which makes it very hard to see what's going on and is often unnecessary, because the same functionality can be obtained using more traditional techniques. 5. Support for multiple configurations (like VPATH builds in Autotools) is incomplete. 6. Checking for headers is sometimes annoying, because the check methods do not return True/False. To sum up, Waf is similar in principle to SCons (scripts are Python), but its different architecture allows it to be faster. However, its code isn't great, it's mostly undocumented, and the maintainer isn't easy to work with. The best that could happen is if someone forked Waf, refactored and documented it. But this might not be realistic. I think Waf 1.5 is still less pain to use than Autotools. *) I read somewhere that having to spell out every source file in Autotools was originally a design decision. The rationale for this is dubious ("people would forget to add files to source control") and makes it easy to keep dead code in the tree. Regards, Krzysztof

2010/1/9 Joshua L. Blocher <verbalshadow@...400...>: Waf has zero issues with recursive scripts (because the compilation is run after all user scripts complete) and zero issues with globbing. If I make a new file, Waf detects it, compiles the new file and relinks the executable, without any need to modify wscripts. That's because the dependency tracking is done at a different level than Make, I can't explain it in detail now, but it obviously works. The reason I don't want to use CMake is that its syntax is weak and it's verbose when doing anything complicated. For example the "if" construct is annoyingly weak. In Python I can just write: sources += ['file1.cpp', 'file2.cpp'], while in CMake I would have to write, if I remember correctly, SET(sources ${sources} file1.cpp file2.cpp). Complicated build systems are most efficiently expressed in general purpose programming languages. The docs situation in Waf can be improved by adding Epydoc comments to the source. The API itself is sound, except a few quirks that can be fixed locally Autotools can't do this because it leaves droppings in the main source dir (e.g. config.guess and aclocal.m4), and Automake creates .in files in the source tree. Didn't check how CMake behaves. Regards, Krzysztof

W dniu 9 stycznia 2010 02:36 użytkownik Michal Suchanek <hramrach@...704...> napisał: The design of Waf is actually its strongest point. It's the implementation that's sometimes lacking, but the same could be said about Inkscape. :) Waf's total source size is only about 200kB (roughly the same as toolbox.cpp), so even extensive modifications are not out of the question. Regards, Krzysztof

W dniu 19 stycznia 2010 09:28 użytkownik <J.B.C.Engelen@...1578...> napisał: It's also not working on Linux (and never was). The main problem is that it tries to put all files beginning with "sp" in a static library, and this causes circular dependencies between "libsp" and the rest of files. The Waf branch currently configures and builds on both Windows and Linux. It should work on Mac OS X with some tweaking, but I don't have any OS X system at hand to test it. It installs correctly on Linux (though I didn't check it extensively), handles updating the translation templates (./waf i18n), and shows the Bazaar revision number and branch name in the About dialog. On Windows it requires a system-wide installation of Python 2.6 to work (which is different from the Python in devlibs, but it doesn't cause any issues, at least during the build). I added some environment magic so that the only variable you need to set before building is DEVLIBS_PATH. Finally, the code is Python, so I think many people will understand most of it without needing to learn the CMake language. Currently I'm working on porting the "dist" command from btool (last piece of the Windows puzzle) and the cxxtest stuff. Regards, Krzysztof