Vala programs and compiling from source

[Toshio Kuratomi]

On Tue, Dec 22, 2009 at 03:52:14PM +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.
> 
> Some what different in that vala is source code that generates plainly
> readable C code. A .dll is a binary library. Its not exactly the same
> arguement.
> 
'm asking for a better definition of source.  If your new definition is any
plainly readable code that upstream builds with, define "plainly readable".

Should we allow swig generated C code for instance?  Pyrex?

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20091222/03ee1429/attachment.sig>