On Fri, 2009-03-20 at 13:05 +0100, Armin Burgmeier wrote:
> On Fri, 2009-03-20 at 13:00 +0100, Murray Cumming wrote:
> > On Fri, 2009-03-20 at 12:55 +0100, Armin Burgmeier wrote:
> > > On Thu, 2009-03-19 at 11:30 +0100, Murray Cumming wrote:
> > > > On Sun, 2009-03-08 at 14:14 +0100, Armin Burgmeier wrote:
> > > > > As libglom/libglom_config.h I would suggest to remove all non-prefixed
> > > > > symbols from it, to prevent conflicts with a "config.h" 
> > > > 
> > > > Thanks for fixing that, though I don't quite understand how you did it.
> > > > 
> > > > However, there are some duplicate defines (the define is in both
> > > > config.h and libglom_config.h files) that are causing warnings in svn
> > > > trunk, at least when doing distcheck. Could you try to fix that? I guess
> > > > that config.h should include libglom_config.h.
> > > 
> > > The problem is that config.h.in is generated by autoheader, which
> > > generates it by scanning the configure.ac file for all the AC_DEFINEs I
> > > think.
> > > 
> > > I believe that to fix this, we would need to get rid of autoheader and
> > > maintain the config.h.in ourselves. This means, whenever adding an
> > > AC_DEFINE to configure.ac, we will either need to add it to config.h.in
> > > or to glom/libglom/libglom_config.h.in, depending on whether its
> > > properly prefixed (and meant for installation) or not.
> > 
> > Fair enough. I hoped you'd find a correct way to still use autoheader,
> > but let's not waste time on it.
> > 
> > > I did this, however, I cannot test it right now since glom trunk does
> > > not build for me because of bug #576069.
> > 
> > You just need to update gtkmm.
> 
> Argh. I had a short look at the ChangeLog to see whether this might have
> been fixed in never versions. Seems it was too short. Thanks.
> 
> I don't think this fix has been merged to the gtkmm-2-14 branch. So we
> should probably either do this, or request gtkmm 2.16 in Glom's
> configure.in.

Please merge it if necessary. I thought I had already. It seems
acceptable to add API there if the old API could not be used.

-- 
[email protected]
www.murrayc.com
www.openismus.com

_______________________________________________
glom-devel-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/glom-devel-list

Reply via email to