Brian, This patch is a short-term solution for Indiana.
The library libglibmm_generate_extra_defs-2.4.so is built once in whole stack. It's built in glibmm. And then glibmm and gtkmm use this library to generate their own executable "generate_extra_defs". Now our solution is glibmm and gtkmm don't build or deliver anything about it. Anyway, we'll raise this issue to module maintainer. Once they agree with removal from tarball, we'll delete this patch. Thanks, -Simon Brian Cameron wrote: > Chris: > > >> /usr/lib/libglibmm_generate_extra_defs-2.4.so delivered by glibmm is >> library is used to generate signals.defs and properties.defs. But gtkmm >> has directly delivered these two defs in tarball. >> >> ARC member has questioned the stability of this interface, and after >> some long discussion, we have decided not to ship the interface. >> > > Here was Danek's comment that I think led to this change. Refer to > email message from Danek dated "02/12/08 11:10" in the case's mail log. > > >>>> Danek Duvall says: >>>> >>> Simon Zheng says: >>> >> Danek Duvall says: >> >> >>>> Is generate_extra_defs something you'd put in a makefile to run over >>>> the .hg and .ccg files to generate a .defs file? >>>> >>> No, generate_extra_defs isn't put into any makefile. Usually >>> generate_extra_defs is run manually by the developer to generate new >>> .defs file, and then put these pre-generated .defs file into source >>> repository. >>> >> Sort of like checking .o files into the repository? Why don't >> developers simply keep the source checked in, and all derived files >> built via the build system? >> > > Based on this comment I get the impression that Danek is suggesting > that the files *not* be delivered with the tarball if they are > autogenerated. I don't think he was suggesting that we avoid > building the files. > > I think he was suggesting we raise this issue with the module > maintainer and find out the best way to fix this problem. > > Brian >
