Bug 49699 - configure problem locating glib.h and gtk.h for JPilotPluginProxy
Summary: configure problem locating glib.h and gtk.h for JPilotPluginProxy
Status: RESOLVED FIXED
Alias: None
Product: kpilot
Classification: Applications
Component: General (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Reinhold Kainhofer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-10-26 00:17 UTC by jeremyhu
Modified: 2008-10-29 19:32 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Uses gtk's own macros to discover CPPFLAGS and LDFLAGS (6.92 KB, patch)
2002-11-07 22:24 UTC, jeremyhu
Details
gtk macros (8.09 KB, text/plain)
2002-11-08 03:50 UTC, jeremyhu
Details
glib macros (8.24 KB, text/plain)
2002-11-08 03:50 UTC, jeremyhu
Details

Note You need to log in before you can comment on or make changes to this bug.
Description jeremyhu 2002-10-26 00:17:17 UTC
Version:            (using KDE Devel)
Installed from:    Compiled sources
Compiler:          gcc 3.2 
OS:          Linux

configure currently just tries <glib.h> to find glib.h which requires the user to setup $CPPFLAGS prior to running configure.  It would be best to try using 'glib-config --cflags' and 'gtk-config --cflags' to do this automatically
Comment 1 groot 2002-11-07 21:24:39 UTC
Subject: Re: configure problem locating glib.h and gtk.h for JPilotPluginProxy

Since I don't know what glib.h is, nor what it's for (the JPilot conduit proxy 
isn't my own code), I can't understand the bug. SInce you seem to know what 
glib-config is supposed to do and how it works, I'd appreciate it if you made 
a patch that did the job. The relevant bit of the configure file is in 
kdepim/kpilot/conduits/JPilotPluginProxy/ in the file configure.in.in. After 
changing it you'll need to do a top-level make -f Makefile.cvs && ./configure 
again to recreate configure and test it. 

Maybe it's as simple as this:

if glib-config --cflags > /dev/null 2>&1 ; then
	HAVE_GLIB=1
	GLIB_INCLUDE=""
	for i in `glib-config --cflags` ; do
		GLIB_INCLUDE="$GLIB_INCLUDE `echo $i | grep '^-I'`"
	done
fi

(ie. check for existence first, then grab the -I lines out of the cflags.) I 
have no way of testing, however.

Comment 2 jeremyhu 2002-11-07 22:24:07 UTC
Created attachment 390 [details]
Uses gtk's own macros to discover CPPFLAGS and LDFLAGS

This patch changes configure.in.in to use the macros that come with gtk/glib to
discover the proper flags.
Comment 3 jeremyhu 2002-11-08 03:50:17 UTC
Created attachment 392 [details]
gtk macros
Comment 4 jeremyhu 2002-11-08 03:50:34 UTC
Created attachment 393 [details]
glib macros
Comment 5 groot 2003-02-13 20:32:25 UTC
Subject: Re: configure problem locating glib.h and gtk.h for JPilotPluginProxy

Hi Jeremy,

Looking at recent code in the JPilot plugin shows me that your patches haven't 
gone in. The bug probably still exists. I'm CC-ing the maintainer of the 
JPilot plugin to make sure he knows.

Comment 6 Juan F. Codagnone 2003-03-17 18:42:54 UTC
still there (cvs from Mon, 17 Mar 2003 14:36:46 -0300) 
the right way to search for glib and gtk in a configure script, is using the 
m4 macros shipped with them. (AM_PATH_GLIB_2_0, ...) you will find it at  
/usr/share/aclocal/glib-2.0.m4 (and there is one for gtk)

i think that it should be merged in the configure script, because not all the 
kde developers must have their copy of gtk (and make -f Makefile.cvs would 
fail with if those m4 don't exist)


Comment 7 Reinhold Kainhofer 2003-08-03 12:06:18 UTC
Thanks for patches. The problem, however, is that KDE's build mechanism does not 
allow .m4 macros for aclocal in the module (i.e. not in /usr/share/aclocal/), thus I 
cannot use these macros.  
However, the macros only use glib-config and gtk-config to detect the correct pathes, 
and then try to compile a test application. We now implemented it in this way. 
 
Note, however, that the JPilotPlugin is not finished anyway, and I don't have any time 
for its further development, so it is disabled and won't be compiled anyway. 
 
Thanks, 
Reinhold