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
