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
Attachment:
pgpSQkwulQKPC.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
