On Tue, Sep 29, 2009 at 11:30 PM, Phil Housley
<undeconstruc...@gmail.com> wrote:
> I've been messing around with a little build tool recently (well,
> actually not that recently, but I've not had any time for a couple of
> months,) aiming to build primarily Vala apps and libraries. Generally
> it's a bit inspired by Maven, so you declare some units to build, and
> let the tool decide what actually needs to be done.
>
> I have a couple of thousand lines of code so far, which is able to
> build itself, using multiple threads, based on a simple configuration
> file.  It discovers source files and compiles them, gathers the
> outputs and queues C compiler tasks to do the next stage, and so on.
> It's fairly cute, but not massively useful so far.
>
> From here, I'm not sure exactly where to go, so I'd be interested in
> knowing what people here might want in a new build tool.  I'd like to
> give it a plugin system to allow running different sorts of tasks, but
> only within a standard build process.  The aim will always be that as
> little as possible has to be configured.
>
> Really the next step should probably be to enable testing, but I'm
> stuck there as well.  Which test frameworks are currently active for
> Vala, and what execution models are they using?  I'd very much like
> testing Vala code to be as easy as in Java, so I'm aiming for the tool
> to be able to discover tests and generate any harnesses required.
>
> Also, I need to push the code somewhere, probably on launchpad, so I
> need a name.  Currently I'm calling it Valapillar, but that's a pretty
> obscure joke even to me, and I know why I chose it.
>
> Sorry for the rambling, message.
>
> Thoughts?
>

I have started thinking about something similar a while ago based on
the declarative maven model, but I got distracted with other things. I
called it weave, maybe you can use that as a name if you want. The
difference was that it wasn't Vala specific but more generic.

The configuration file looked like this:

project('core') {
        name = 'Core'
        description = 'Class library for Vala'
        version = '0.1.0'

        conventions {
                org.gnu
        }

        tools {
                lang.vala
        }

        checks {
                libxml-2.0 >= 2.6
                valac >= 0.5.7
        }

        artifact('libcore') : lang.vala.library {
                abi:version = '0.0.0'
        }
}

So a project defines a set of conventions (define the source code
layout), a set of tools (compilers, preprocessors...) and a set of
checks (each tool process the checks, that way we can check for both
the vapi and the pkgconfig files). Once these 3 components defined,
you define the artifacts. I am not sure if this would be a good
approach, but those were my initial ideas.

--
Ali
_______________________________________________
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Reply via email to