Re: strawman (Was Re: build systems)

["Mikkel Kamstrup Erlandsen" <mikkel kamstrup gmail com>]

On 12/11/2007, Mikkel Kamstrup Erlandsen <mikkel kamstrup gmail com> wrote:

On 12/11/2007, Ali Sabil <ali sabil gmail com> wrote:

>
> However, the most important point for this discussion is that this
> approach makes it hard to provide a high-level UI a'la Eclipse or Visual
> Studio which is what many many people are used to. One way to do this is
> to use a declarative programming language (e.g. XML) to express the
> build process.
>
I agree with you concerning this, and if you took time to check, WAF
already have an xml representation using wscript_xml files iirc.

The problem with declarative approaches is that you cannot easily
integrate configure checks, WAF solves this by allowing python
snippets to be included for the configure check.

Eh, why not?

<check package="glib-2.0" minimalVersion="2.12"/>

Other more advanced constructs (such as checking for a specific Python package or other) can be implemented with a plugin system like Ant have, or other means.

I think we should really investigate WAF, and how to make use of the
XML representation to integrate with let's say Eclipse ?

Yes, the Waf XML representation should definitely be examined.

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


Cheers,
Mikkel