Re: Glom 1.10 soon

[Armin Burgmeier <armin arbur net>]

On Fri, 2009-03-20 at 13:16 +0100, Murray Cumming wrote:
> 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.

I merged the commit to gtkmm-2-14.

Armin