GNOME Bugzilla – Bug 489865
goocanvasmm installation dirs
Last modified: 2011-01-16 23:37:01 UTC
Here we go again. :-) This is from goocanvasmm-0.3.0: /usr/include/goocanvasmm-0.1/goocanvasmm.h /usr/include/goocanvasmm-0.1/goocanvasmm/*.h /usr/include/goocanvasmm-0.1/goocanvasmm/private/*_p.h /usr/lib/goocanvasmm-0.1/include/goocanvasmmconfig.h /usr/lib/libgoocanvasmm-0.1.* /usr/lib/libgoocanvasmm-0.1/proc/m4/convert.m4 /usr/lib/libgoocanvasmm-0.1/proc/m4/convert_libgoocanvasmm.m4 /usr/lib/pkgconfig/goocanvasmm-1.0.pc 1) goocanvasmm (in includes and .pc) or libgoocanvasmm (libinclude dir)? 2) 0.1 (almost everything) or 1.0 (.pc filename)? 3) goocanvasmmconfig.h is in different dir than proc/m4. 4) .pc file's Cflags: does not include the goocanvasmmconfig.h libinclude dir. P.S. the goocanvasmm-0.3.0 tarball seems to be built with glibmm-2.14, which uses Glib::wrap_auto_interface<>() instead of Glib::wrap_auto(), but configure.ac demands only glibmm-2.4 >= 2.10.
Thanks. I'll fix all this.
> 1) goocanvasmm (in includes and .pc) or libgoocanvasmm (libinclude dir)? > 3) goocanvasmmconfig.h is in different dir than proc/m4. It was just 3) that was adding a libgoocanvasmm-1.0 directory. Fixed in svn. > 2) 0.1 (almost everything) or 1.0 (.pc filename)? I'm not too worried about this and I do it quite often. I'll change the library name and include dir to 1.0 when it's API stable. I know it's not really necessary, but it does make sure that people start with a clean directory without any old files when we hit 1.0. > 4) .pc file's Cflags: does not include the goocanvasmmconfig.h libinclude dir. Fixed. Unfortunately, we can't easily require the correct glibmm in configure, because the new API is in later version of both glibmm 2.12 and glibmm 2.14.