[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Vala programs and compiling from source



On Tue, Dec 22, 2009 at 02:16:13PM +0000, Bastien Nocera wrote:
> 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.
> 
So this is interesting.  Alternatives that I see here:

* Build rygel from the generated C
* Build vala from a snapshot so it can be used to build rygel
* Drop rygel from Fedora until we can build from source.

There's limited precedent for all of these.  We've shipped packages
where C source had been precompiled from yacc, for instance.  The question
is whether that was a bug to be addressed when we find it happening or
something we want to accept as okay.

> > 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 is plainly an insufficient definition.  For instance, mono packages
sometimes ship with .dll files that their build scripts rely on "linking"
into the build.  Those are not source no matter what upstream's build
requires.

-Toshio

Attachment: pgpmirm2IicbG.pgp
Description: PGP signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]