On Monday 10 March 2008, Udo Richter wrote: > clemens kirchgatterer wrote: > > structure bin, lib, include, share, ... if i want to compile software > > using the libs (and headers) of opt1 i only have to do > > "PKG_CONFIG_PATH=/opt1 make" and to start that program > > "LD_LIBRARY_PATH=/opt1 prog". given the Makefile of prog uses > > pkg-config properly. > > And thats so much better than make INCLUDES=/opt1/usr/include? If "make INCLUDES=..." or manually changing INCLUDES in Makefile [0] works better for you than using pkg-config, by all means use/do it. The patch I posted does not prevent that; it's possible just like it was before the patch. The intention of the patch is to make it more likely that there would be one thing less to touch when building VDR for most users. I think that's much more likely when using pkg-config than when hardcoding stuff; that's why I'm suggesting it to be used by default rather than telling people to build with "make INCLUDES=$(pkg-config --cflags-only-I freetype2 fontconfig) ..." > My point is: There's one version of the libs that is in the default > library search path. Shouldn't there also be one header in the default > header search path then? Why do you assume that there are any versions of the libs in default lib search paths? There might not be any. In addition to setting include dirs, the pkg-config patch also takes care of library names and library dirs. It could also take care of other non"-I" CFLAGS possibly needed (replace --cflags-only-I with --cflags, I didn't do that because it doesn't seem well placed in a variable called INCLUDES and my intention was not to make too many changes to Makefile). And it could even handle RPATHs if the lib dirs are not in default search paths, but that's theoretical/guesswork - I haven't checked if any *.pc does anything like that. > Btw. do I need to call /opt1/usr/bin/freetype-config? or will any > freetype-config be ok? If using pkg-config, I don't know why you'd call freetype-config at all. _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr