Re: strawman (Was Re: build systems)
- From: jamie <jamiemcc blueyonder co uk>
- To: Mikkel Kamstrup Erlandsen <mikkel kamstrup gmail com>
- Cc: Olav Vitters <olav bkor dhs org>, desktop-devel-list gnome org, David Zeuthen <david fubar dk>
- Subject: Re: strawman (Was Re: build systems)
- Date: Mon, 12 Nov 2007 22:58:19 +0000
On Mon, 2007-11-12 at 23:50 +0100, Mikkel Kamstrup Erlandsen wrote:
> On 12/11/2007, Mikkel Kamstrup Erlandsen <mikkel kamstrup gmail com>
> 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
> 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!!! :)
] [Thread Prev