Vala programs and compiling from source

Yaakov Nemoy loupgaroublond at gmail.com
Tue Dec 22 18:39:54 UTC 2009


2009/12/22 Bastien Nocera <bnocera at redhat.com>:
> On Mon, 2009-12-21 at 15:53 -0800, Toshio Kuratomi wrote:
>> On Mon, Dec 21, 2009 at 05:00:58PM +0000, Peter Robinson wrote:
>> > Hi,
>> >
>> > > I recently submitting Deja-dup, a backup program written in Vala for
>> > > review at
>> > >
>> > > https://bugzilla.redhat.com/show_bug.cgi?id=540761
>> > >
>> > > Vala is described in more detail at http://live.gnome.org/Vala. Deja-dup
>> > > like many Vala programs include both the Vala source code and the C
>> > > "source code" to avoid a build time requirement of Vala and also because
>> > > Vala is still in a rapidly evolving stage.  Do I need to build from the
>> > > original Vala source code or can I consider the machine generated C as
>> > > "source"?
>> >
>> You should be building from the vala source.
>>
>> > For rygel to date I've used the C as "source" unless I've needed to
>> > patch a bug or build issue with it when you then need to regenerate
>> > it.
>> >
>> Sounds like rygel should as well.
>
> That won't work. The upstream uses Vala git, which didn't allow
> recompiling rygel from the version of Vala in Fedora.
>
>> When in doubt, build from the source that upstream is going to be modifying,
>> fixing bugs in directly, etc.
>
> When in doubt, use the sources that upstream is providing as the sources
> to build from, in this case the C files rather than the Vala ones (even
> if both are actually in the tarball).

This makes me uneasy in a worse way than autotools. Even if the C is human editable, it really makes it harder for the user to fix and rebuild code, especially in a way that upstream will accept it. With autotools and similar systems, the generated code is used to compile code, but isn't part of the codebase that is actually running in the binary. Even if this is valid within the GPL, it goes against Fedora's mission to provide a codebase that is completely self hosting.

Toshio mentioned a bit further down one option is to ship a checkout from Vala instead of the upstream release. Perhaps we need to put pressure on the Vala community to make more frequent releases and to focus on sticking to releases when developing applications. 

-Yaakov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 272 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20091222/3d719939/attachment.bin 


More information about the devel mailing list