Re: strawman (Was Re: build systems)

[jamie <jamiemcc blueyonder co uk>]

On Mon, 2007-11-12 at 23:50 +0100, Mikkel Kamstrup Erlandsen wrote:
> 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
> 
> 

its a nice idea

I guess whats needed is some kind of converter to convert to and from
xml and autofoo with appropriate macros and/or xslt

I guess the only snag is finding a volunteer to do it - which most
likely means you!!! :)



jamie