I need some help with the new libbeagle-0.3.0. This one is listed in pkg-config with "libbeagle-1.0". The configure script of kerry (and also brasero and yelp) are explicit checking for "libbeagle-0.0". Upstream hasn't catched up the new beagle, yet, so I have to figure out what is the best way of preparing my package (kerry) for the new libbeagle version. And here I need some help because I'm not very familiar with configure scripts. :)
My attempt here is to avoid a patch and change the libbeagle version with sed:
%build unset QTDIR || : ; . /etc/profile.d/qt.sh export QTLIB=${QTDIR}/lib QTINC=${QTDIR}/include
# libbeagle-version is now 0.1 sed -i 's/LIBBEAGLE_PACKAGES="libbeagle-0.0"/LIBBEAGLE_PACKAGES="libbeagle-1.0"/' configure
%configure --disable-rpath --disable-debug make %{?_smp_mflags}
A scratch build seems to be fine: http://koji.fedoraproject.org/koji/taskinfo?taskID=285293
But I think there would be better options to to this.
Sebastian
Am Mo 10.Dezember 2007 schrieb Sebastian Vahl:
I need some help with the new libbeagle-0.3.0. This one is listed in pkg-config with "libbeagle-1.0". The configure script of kerry (and also brasero and yelp) are explicit checking for "libbeagle-0.0". Upstream hasn't catched up the new beagle, yet, so I have to figure out what is the best way of preparing my package (kerry) for the new libbeagle version. And here I need some help because I'm not very familiar with configure scripts. :)
My attempt here is to avoid a patch and change the libbeagle version with
sed:
%build unset QTDIR || : ; . /etc/profile.d/qt.sh export QTLIB=${QTDIR}/lib QTINC=${QTDIR}/include
# libbeagle-version is now 0.1 sed -i 's/LIBBEAGLE_PACKAGES="libbeagle-0.0"/LIBBEAGLE_PACKAGES="libbeagle-1.0"/ ' configure
%configure --disable-rpath --disable-debug make %{?_smp_mflags}
A scratch build seems to be fine: http://koji.fedoraproject.org/koji/taskinfo?taskID=285293
But I think there would be better options to to this.
Sebastian
Oh. I've forgotten to copy the part from the configure script:
# LIBBEAGLE_CFLAGS: cflags for compiling libbeagle dependant sources # LIBBEAGLE_LIBADD: libbeagle libraries (-l options) # LIBBEAGLE_LDFLAGS: flags containing path to libbeagle libraries (-L options)
LIBBEAGLE_PACKAGES="libbeagle-0.0" LIBBEAGLE_VERSION="0.2.5" { echo "$as_me:$LINENO: checking for libbeagle-0.2.5 (at least $LIBBEAGLE_VERSION)" >&5 echo $ECHO_N "checking for libbeagle-0.2.5 (at least $LIBBEAGLE_VERSION)... $ECHO_C" >&6; }
if $PKG_CONFIG --atleast-pkgconfig-version 0.15 ; then if $PKG_CONFIG --atleast-version $LIBBEAGLE_VERSION $LIBBEAGLE_PACKAGES
/dev/null 2>&1 ; then LIBBEAGLE_CFLAGS="`$PKG_CONFIG --cflags
$LIBBEAGLE_PACKAGES`" LIBBEAGLE_LIBADD="`$PKG_CONFIG --libs-only-l --libs-only-other $LIBBEAGLE_PACKAGES`" LIBBEAGLE_LDFLAGS="`$PKG_CONFIG --libs-only-L $LIBBEAGLE_PACKAGES`" { echo "$as_me:$LINENO: result: yes"
&5
echo "${ECHO_T}yes" >&6; } fi else if $PKG_CONFIG --atleast-version $LIBBEAGLE_VERSION $LIBBEAGLE_PACKAGES
/dev/null 2>&1 ; then LIBBEAGLE_CFLAGS="`$PKG_CONFIG --cflags
$LIBBEAGLE_PACKAGES`" LIBBEAGLE_LIBADD="`$PKG_CONFIG --libs-only-l $LIBBEAGLE_PACKAGES`" LIBBEAGLE_LDFLAGS="`$PKG_CONFIG --libs-only-L $LIBBEAGLE_PACKAGES`" { echo "$as_me:$LINENO: result: yes" >&5 echo "${ECHO_T}yes" >&6; } { echo "$as_me:$LINENO: WARNING: you may need to run make LDFLAGS=-pthread to compile arts" >&5 echo "$as_me: WARNING: you may need to run make LDFLAGS=-pthread to compile arts" >&2;} fi fi
if test -z "$LIBBEAGLE_LIBADD"; then { echo "$as_me:$LINENO: result: not installed" >&5 echo "${ECHO_T}not installed" >&6; } DO_NOT_COMPILE="$DO_NOT_COMPILE kerry gmcop" fi
On Mon, 2007-12-10 at 13:56 +0100, Sebastian Vahl wrote:
I need some help with the new libbeagle-0.3.0. This one is listed in pkg-config with "libbeagle-1.0". The configure script of kerry (and also brasero and yelp) are explicit checking for "libbeagle-0.0". Upstream hasn't catched up the new beagle, yet, so I have to figure out what is the best way of preparing my package (kerry) for the new libbeagle version. And here I need some help because I'm not very familiar with configure scripts. :)
My attempt here is to avoid a patch and change the libbeagle version with sed:
Seems fine. This is one of my pet-peeves with pkgconfig, by embedding a "ABI/API/Arbitrary random version" in the identifier name, it makes looking for the related values much much more difficult.
Instead of just asking pkgconfig for libgtkhtml's libs/headers, I've got to check for libgtkhtml-3.14, then libgtkhtml-3.12, libgtkhtml-3.10, libgtkhtml-3.08, libgtkhtml-3.06, libgtkhtml-3.04, and so on, ad infinitum.
To be fair, this isn't pkgconfig's fault, it's GNOME's fault, as it seems to be the one doing this. Evolution recently dropped this practice, one can only hope that the rest of GNOME follows.
~spot
On Mon, 2007-12-10 at 11:35 -0500, Tom "spot" Callaway wrote:
On Mon, 2007-12-10 at 13:56 +0100, Sebastian Vahl wrote:
I need some help with the new libbeagle-0.3.0. This one is listed in pkg-config with "libbeagle-1.0". The configure script of kerry (and also brasero and yelp) are explicit checking for "libbeagle-0.0". Upstream hasn't catched up the new beagle, yet, so I have to figure out what is the best way of preparing my package (kerry) for the new libbeagle version. And here I need some help because I'm not very familiar with configure scripts. :)
My attempt here is to avoid a patch and change the libbeagle version with sed:
Seems fine. This is one of my pet-peeves with pkgconfig, by embedding a "ABI/API/Arbitrary random version" in the identifier name, it makes looking for the related values much much more difficult.
Instead of just asking pkgconfig for libgtkhtml's libs/headers, I've got to check for libgtkhtml-3.14, then libgtkhtml-3.12, libgtkhtml-3.10, libgtkhtml-3.08, libgtkhtml-3.06, libgtkhtml-3.04, and so on, ad infinitum.
What you say only applies if a library's API is backward compatible to its predecessor.
To be fair, this isn't pkgconfig's fault, it's GNOME's fault, as it seems to be the one doing this.
Right, if a library's upstream is "backward compatible" they shouldn't bump the *.pc's file name, but only the internal version number.
Evolution recently dropped this practice, one can only hope that the rest of GNOME follows.
This advice is short-sighted.
Versioned *.pc are one way (another one is using a different PKG_CONFIG_PATH) to permit parallel installation of API incompatible packages. So my advice would be library upstreams not to tie their *.pc's file names to package versions, but to API-versions, instead.
Ralf
packaging@lists.fedoraproject.org
-
Ralf Corsepius -
Sebastian Vahl -
Tom Callaway