GNOME Bugzilla – Bug 129719
libgnomeprintmm-2.5.0 fails to build with older gcc
Last modified: 2004-12-22 21:47:04 UTC
gcc version 2.95.4 20020723 (prerelease) Once again, need to change a static_const: patch -p1 << \EOF diff -ru libgnomeprintmm-2.5.0.orig/libgnomeprint/libgnomeprintmm/font.cc libgnomeprintmm-2.5.0/libgnomeprint/libgnomeprintmm/font.cc --- libgnomeprintmm-2.5.0.orig/libgnomeprint/libgnomeprintmm/font.cc 2003-12-07 17:08:33.000000000 -0800 +++ libgnomeprintmm-2.5.0/libgnomeprint/libgnomeprintmm/font.cc 2003-12-19 21:53:03.000000000 -0800 @@ -180,7 +180,7 @@ Glib::RefPtr<Font> Font::find_closest(const Glib::ustring& family, FontWeight weight, bool italic, double size) { - return Glib::wrap(gnome_font_find_closest_from_weight_slant((const guchar*)family.c_str(), static_cast<GnomeFontWeight>(weight), static_cast<int>(italic), size)); + return Glib::wrap(gnome_font_find_closest_from_weight_slant((const guchar*)family.c_str(), (GnomeFontWeight)(weight), static_cast<int>(italic), size)); } Glib::RefPtr<Pango::Font> Font::get_closest_pango_font(const Glib::RefPtr<Pango::FontMap>& map, double dpi) const EOF Now, I understand this is a generated file. However, it's an issue with gtkmmproc which I cannot address. All I can do it point out the issue. Why can I not address it? 1) Time to work on it. 2) Not sure where to find it. I *think* I've installed every package off of gnome.org, though I may have missed whichever one has this tool. Pointers would be appreciated. 3) There also appears to be no entries in any Makefiles that would allow me to make my own local tweaks and have the build system automatically regen the files. Anyway, if the decision is made to not support older compilers, then it would be appropriate to add that as an autoconf feature test.
> 2) Not sure where to find it. I *think* I've installed every package > off > of gnome.org, though I may have missed whichever one has this tool. > Pointers would be appreciated. gtkmmproc is part of gtkmm. You can read more about it in gtkmm/docs/internals/ The code that you need to change is probably either in the .ccg file in libgnomeprintmm/libgnomeprint/src/, or in a .m4 file in libgnomeprintmm/tools/m4. It could be a generic enums conversion, but I think you would have seen that while building gtkmm itself. > There also appears to be no entries in any Makefiles that would >allow me >to make my own local tweaks and have the build system automatically regen > the files. Generated files should rebuild automatically when you change the source files. I'm not sure what you mean here. You _might_ need to configure with enable-maintainer-mode, which autogen.sh does automatically, which you must use when using cvs, which you should use to create patches.
Ok... actually I've found out that it's no longer gtkmmproc but rather gmmproc and info located in glibmm/docs/internal, which explains why I couldn't find it. Joys of transitioning. :-> Still, since glibmm-2.3.x is out, I would have expected other GNOMEVER2.5 stuff to be using that one now. Maybe still too early in the transition? Anyway, the corresponding .ccg file is pretty minimal; I saw nothing in there to obviously tweak. And also, since I'm seeing this same issue in lots of other projects, I suspect it's really something that will have to be dealt with in the .m4 files. Still, I'm not sure I agree with your idea that regenerated files should not be rebuilt if the source file is touched. After all, imagine a project that using yacc/bison that ships with a pregenerated .c file. If I modify the .y file, I expect the .c file to get updated. I see similar things with IDL files in the Gnome project. There is definite precedence for it and I think it would fall under "least surprise" to have the ability to regen them by default.
Of course generated files should be regenerated if the source file has changed.
We will not try to support gcc 2.9* for gtkmm 2.4, but we will happily apply patches that anyone provides. Please reopen this bug if you have a patch that fixes this for you.