On Tue, Sep 29, 2009 at 11:30 PM, Phil Housley
<[email protected]> 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
[email protected]
http://mail.gnome.org/mailman/listinfo/vala-list
