On 12/11/2007, jamie <[EMAIL PROTECTED]> wrote: > > 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!!! :)
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
_______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
