Re: strawman (Was Re: build systems)

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

On 12/11/2007, jamie <jamiemcc blueyonder co uk> wrote:

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!!! :)

You know what? Maybe I will. I have been sketching a design in my head and I think it can be rocking quite hard :-)

While I would probably not go the XSLT route, an initial stab in Python converting to auto* would probably be my choice.

Maybe I should punk some of the other Pythonists at the office to help me out (Mads - you know who you are...).

Cheers,
Mikkel