Re: strawman (Was Re: build systems)
- From: "Mikkel Kamstrup Erlandsen" <mikkel kamstrup gmail com>
- To: jamie <jamiemcc blueyonder co uk>
- Cc: desktop-devel-list gnome org
- Subject: Re: strawman (Was Re: build systems)
- Date: Tue, 13 Nov 2007 13:15:53 +0100
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]