Brian: As Simon mentioned, our current strategy is not to deliver libglibmm_generate_extra_def.so, so for gtkmm, we have to avoid to build it. We'll remove the patch definitely if we can get support from the module owner.
Chris simon.zheng at sun.com ??: > 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 >> >> > >
