[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



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?

> 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.

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.

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

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/

Attachment: pgpCMoqP3TSql.pgp
Description: PGP signature


Reply to: