I took a closer look at the WAF XML serialization. It is indeed very waf-specific, relies on inlined Python code, not really XML-ish in style. So I would not go down that road.
I put up a small example more in the way I would do things for the imaginary libbaboom: http://grillbar.org/cook/recipe.xml
Here are the ideas outlined:
* Be explicit - never have existence of special values or files be implied by some odd check or construct. If you create files you specify the names and dirs they go in, and if you run a check the value of the check is stored in a named variable.
* Note in the checkDepends target that we have pre-defined tool names. Some are generic, fx. "cc" which means "a c compiler", others are specific such as gtk-doc.
* It is build system implementation agnostic (can be implemented on top of auto*, waf, or what ever)
* Using the "tool" metaphor we can basically compile anything from assembler to Java classes.
* You can understand the build recipe without documentation
* Provide helper elements for 95% of the common build actions to avoid "scripting", ie; selecting files matching a given pattern, checking for various stuff, basic file operations, search/replace etc.
Yes, this is very close to "generic Ant". Ant is a widely adopted and thoroughly tested standard. We should not disregard the enormous testing that framework has seen.
Other pros for something close to Ant are:
- Easier for IDEs already supporting Ant to adopt
- Easier for developers already knowing Ant to adopt