Re: [Vala] Building a build tool

[Abderrahim Kitouni <a kitouni gmail com>]

2009/10/1 Phil Housley <undeconstructed gmail com>:
> 2009/9/30 Ali Sabil <ali sabil gmail com>:
> > On Tue, Sep 29, 2009 at 11:30 PM, Phil Housley
> > <undeconstructed gmail com> wrote:
> > > I've been messing around with a little build tool recently
Me too (althought not so recently and I didn't get it to build anything ;-()
> ...
> > > 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.
>
> That is a pretty nice name for this sort of thing, if you are sure
> that you won't be using it, I might take the liberty.
>
> > 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.
>
> While I'm going with XML, it seems like we were thinking quite
> similarly.  My current test project looks like:

I'd prefer not using XML, I think the project description should be
human-editable.
(besides the fact that it's too verbose). Ali's syntax seems fine to
me (in spite of being a bit verbose, I think that if we are going to
scan for source files, we don't need to explicitly write
"lang.vala.library", it could be just "library" and the tool will see
that it's written in vala).

> <?xml version="1.0" encoding="UTF-8" ?>
>
> <project xmlns="http://example.org/vala/project";>
>
>        <group_id>lp.undeconstructed</group_id>
>        <project_id>valapillar</project_id>
>
>        <version>0.0.1-SNAPSHOT</version>
>
>        <allunits>
>
>                <packages>
>                        <package name="glib-2.0" min="2.20" />
>                        <package name="gio-2.0" min="2.20" />
>                        <package name="gee-1.0" min="0.1.4" max="0.1.4" />
>                        <package name="core-0.1" min="0.1.0" max="0.1.0" />
>                </packages>
>
>        </allunits>
>
>        <units>
>
>                <unit name="vpl">
>                        <type>application</type>
>                        <path>main</path>
>                </unit>
>
>        </units>
>
> </project>
>
> This defines project metadata, some shared configuration, and then a
> build artifact, at a path beginning src/main.  What I haven't decided
> yet is how to define which tools are needed, mainly because I'm not
> sure exactly how big a unit can be.  Building a Vala app or library
> needs several tools, so maybe a unit could even have multiple source
> types without really changing the concept.
>
> One thing I'm thinking of trying next is having packaging as a part of
> the build.  I think it would be interesting to have a unit, for
> example, at src/debian, which depended on the application unit and
> then built a package automatically, but there are all sorts of issues

Maybe we can make it (in addition to a build tool) a "lightweight
$HOME package manager" this would have the advantages you cite without
the problems outlined by Andrea (and we could even make a nice gui so
that source tarballs could be "installed" directly)

> like where to put support files - with the application, with the
> package, or separately in a resource unit (current favourite.)
I think it can get the needed informations from the build description
(description, dependencies, etc.), and the tool would generate a
"template" that should be extended by the user (or the package
maintainer)

> Also, I still don't know about unit testing - even down to when in the
> process to insert it.  Oh well, I'll carry on pondering.

Someone recently announced a unit testing tool for vala, try to take a
look at it.

Anyway, these are just thoughts. It would be better when we see the code ;-p

Abderrahim