On Mon, 2007-11-12 at 23:50 +0100, Mikkel Kamstrup Erlandsen wrote: > On 12/11/2007, Mikkel Kamstrup Erlandsen <[EMAIL PROTECTED]> > wrote: > On 12/11/2007, Ali Sabil <[EMAIL PROTECTED]> 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 _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
