GNOME Bugzilla – Bug 711082
GDBus codegen no longer backwards compatible.
Last modified: 2013-10-30 11:34:52 UTC
With this commit we migrate some of the GIO stuff to itself internally use the new private data: commit 32747def4bb4cce7cfc4f0f8ba8560392ec9ad3d Author: Emmanuele Bassi <ebassi@gnome.org> Date: Tue Jun 11 00:29:58 2013 +0100 gio: Use the new private instance data declaration Use the newly added macros, and remove the explicit calls to g_type_class_add_private(). However, changes were also made to gio/gdbus-2.0/codegen/codegen.py, which effects how other project's sources are generated. These changes did not add any generated backwards compatibility in the sources, no GLIB_VERSION_CHECK() to allow compiling sources for older targets. While this should not in theory be a problem, since you should have the gdbus-codegen tool which matches your glib at compilation time, it's broken for: a.) projects which may have committed generated files (yeah, we dont care about them but...) b.) projects which use normal autotools setups and create dist tarballs. The generated sources, typically specified as BUILT_SOURCES, are distributed with a dist tarball and make will not try to rebuild them. Since you built them with new glib, and send the tarbal to someone with normal, not bleeding edge glib, it will not build for them. I'm reporting this as it happened to me while wrapping up and distributing a tarball of EDS to a third party, but I suspect it will happen alot very soon, the more people generate tarballs using recent gdbus-codegen...
Pretty sure this is a dup of bug 710133 - if so please confirm the fix, if not feel free to reopen. *** This bug has been marked as a duplicate of bug 710133 ***
> The generated sources, typically specified as BUILT_SOURCES, are > distributed with a dist tarball and make will not try to rebuild > them. That's your problem (why did you think this was a good idea?) and in bug 710133 comment 3 we specifically added language to the man page to say that you should never do that, see https://git.gnome.org/browse/glib/commit/?id=f2c4eb8cbb20424a5e715b7f423d96ba9a30ac7f for the commit.
(In reply to comment #2) > > The generated sources, typically specified as BUILT_SOURCES, are > > distributed with a dist tarball and make will not try to rebuild > > them. > > That's your problem (why did you think this was a good idea?) It's not that it's a good idea, it's what is current practice (why did you think the idea to put that in BUILD_SOURCES was mine ?) While the added comment is certainly a good thing: + <para> + It is important to note that the generated code should not be + checked into revision control systems, nor it should be included + in distributed source archives. + </para> I'm curious how reading that would cause someone to realize that listing built sources under BUILT_SOURCES is a bad idea. If it's my problem sure, it's worth noting that it will also be many other people's problem as well (knowledge of automake is fire and forget, copy & paste, if you remember how it's done then you've lost time somewhere). A more effective solution might be to add an .m4 macro or gtk-doc like template Makefile to gnome-common. I'll anyway adapt the EDS makefiles, the above is just a suggestion.
(In reply to comment #3) > + <para> > + It is important to note that the generated code should not be > + checked into revision control systems, nor it should be included > + in distributed source archives. > + </para> > > I'm curious how reading that would cause someone to realize > that listing built sources under BUILT_SOURCES is a bad idea. listing under BUILT_SOURCES is not problematic. the problematic part, which I've seen in various projects, is doing: libfoo_la_SOURCES += $(BUILT_SOURCES) whereas the correct way to handle that is: nodist_libfoo_la_SOURCES += $(BUILT_SOURCES) which, as much as I'd like, cannot be abstracted into a m4 macro like the ones we use for the GSettings schemas or for i18n of desktop files.