Re: change glib-config to pkgconfig in configure.in

[Francesco Namuri <francesco@namuri.it>]

Hi Neil,
Il giorno ven, 15/05/2009 alle 16.11 +0100, Neil Williams ha scritto:
> On Fri, 15 May 2009 16:24:03 +0200
> Francesco Namuri <francesco@namuri.it> wrote:
> 
> > Hi,
> > I'm trying to solve bug #523713, it regards pmidi package, the problem
> > is that the build depends on glib 1.2 that is going to be removed from
> > unstable. I've seen that the program compiles fine with glib 2.0, but
> > the configure look only to 1.2 version using the glib-config tool.
> > 
> > Now, I've managed to solve this problem changing these lines in
> > config.in
> 
> ? config.in ? That doesn't sound like a standard autotools file. The
> source package contains configure.in - I'm assuming you mean that.
> 
> Once configure.in is modified, the configure script needs to be
> regenerated. That can cause problems with packages that haven't had an
> upstream release in a while.
> 
> This is a rather worrying snippet:
>     dnl If using the system's GLIB library, setup 
>     dnl will exclude the included GLIB
> 
> included copy of GLIB 1.2 ???
> 
> I know it's only a single small file but still, is there an upstream
> for pmidi?

the last version of pmidi (1.6.0) has been released in December 2003,
after this no more official relases. To solve this problem can I
repackage the source removing these two files?

> > from:
> > 
> >        if test "$included_glib" = "auto" || test "$included_glib" =
> > "no"; then AC_PATH_PROG(GLIBCNF, glib-config, true, $PATH)
> >                 CFLAGS="$CFLAGS `$GLIBCNF --cflags`"
> >                 LIBS="$LIBS `$GLIBCNF --libs`"
> >                 WITH_INCLUDED_GLIB=0
> >                 AC_SUBST(GLIBCNF)
> >         fi
> > 
> > to something like:
> > 
> >         if test "$included_glib" = "auto" || test "$included_glib" =
> > "no"; then AC_PATH_PROG(GLIBCNF, glib-config, true, $PATH)
> 
> The AC_PATH_PROG test will fail as glib-config no longer exists. Why
> still test for it? You need to test for where GLIBCNF is used later on
> in the package - if it is *off* (as it would be with only glib-2.0)
> this could end up causing the data from pkg-config being ignored.

I've tried and the configure works, the builds fine linking to new
glib-2.0. 

> It looks like it will be OK though. objdump -p certainly shows a link
> against glib-2.0
> 
> Also, most packages look up the path to pkg-config and use that
> variable. It is a more portable method.
> 
> >                 CFLAGS="$CFLAGS `pkg-config --cflags glib-2.0`"
> >                 LIBS="$LIBS `pkg-config --libs glib-2.0`"
> 
> That overrides those variables. More common practice is to append but
> if the package uses no others, it should be OK.
> 
> >                 WITH_INCLUDED_GLIB=0
> >                 AC_SUBST(GLIBCNF)
> >         fi
> > 
> > 
> > Is it a good solution, or it's a bad workaround?
> 
> It's probably only a partial solution. You'll need to be sure that
> other things haven't changed as a result and you'll need to see what
> other effects re-running the autotools may cause. (autoreconf -f).
> You'll almost certainly have a bloated .diff.gz.

Yes, the .diff.gz, contais all the autotools regenerated files...

> What patch system are you proposing to use to implement this change to
> configure.in ?

I have not considered this issue, maybe simple path system? But I don't
know if another patch system can offer enhancements managing a problem
like this one.

Thanks for your help,
francesco