After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 159847 - [build] hardcoded path for musepack headers in configure
[build] hardcoded path for musepack headers in configure
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins
0.8.6
Other FreeBSD
: Normal normal
: 0.8.7
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2004-11-29 15:07 UTC by Koop Mast
Modified: 2004-12-17 14:13 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Koop Mast 2004-11-29 15:07:43 UTC 
In the configure script in the musepack section there is this line:

CPPFLAGS="-I/usr/include/musepack $CPPFLAGS"

On linux systems musepack is probably installed in the /usr/include/musepack.
So no problem here, but on FreeBSD (and maybe other OS's) they are put in
/usr/local/include/musepack. With the result that the configure script can't 
find the includes. 

Because default CPPFLAGS points to /usr/local/include.
Comment 1 Ronald Bultje 2004-12-03 23:23:19 UTC 
This was just the quickest possible hack. I don't know how any of this works or
how to automatically choose the right prefix for includepaths when finding headers.
Comment 2 Stephane Loeuillet 2004-12-12 23:36:04 UTC 
couldn't we use something like this ?

GST_CHECK_LIBHEADER(MUSEPACK, musepack, , , musepack/mpc_dec.h, [
    HAVE_MUSEPACK="yes"
    AC_SUBST(MUSEPACK_CFLAGS)
    AC_SUBST(MUSEPACK_LIBS)
    ], [HAVE_MUSEPACK="no"])
Comment 3 David Schleef 2004-12-17 01:10:25 UTC 
Other packages seem to use the '#include <musepack/xxx.h>' form, so we should
too.  And if we're searching for musepack/mpc_dec.h, things Just Work.

Fixed in CVS.