2009/10/4 Abderrahim Kitouni <a.kito...@gmail.com>:
> 2009/10/1 Phil Housley <undeconstruc...@gmail.com>:
>> 2009/9/30 Ali Sabil <ali.sa...@gmail.com>:
>>> 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
> 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).
Only the actual configuration loading phase is tied to the format, so
it's easy enough to change. The biggest advantage of all with XML for
something like this is the already existing pull parsers, which easily
allows different plugins to have their own configs.
>>
>> <?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)
In terms of making things available for development, I could see that
fitting in, but not as a more general system. It would be nice to
have automatic configuration and install of libraries to something
like ~/local/dev/libfoo-1.0/{bin,vapi,h}, and then allow those to be
used to develop against, but any more support would always be pushing
towards trying to be a real package manager, even if you are only
targetting the home directory.
>> 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.
I've been trying for a few days, but haven't found the time yet. I've
also being wanting to have a play with Core's testing thing, and I'm
sure there was at least one other announced on the list. VUnit?
> Anyway, these are just thoughts. It would be better when we see the code ;-p
That would probably help. I'll try and reserve this evening for it,
but who knows what will happen.
> Abderrahim
--
Phil Housley
_______________________________________________
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
