Message ID | 200803062137.09792.ville.skytta@iki.fi |
---|---|
State | New |
Headers |
Received: from smtp4.pp.htv.fi ([213.243.153.38]) by www.linuxtv.org with esmtp (Exim 4.63) (envelope-from <ville.skytta@iki.fi>) id 1JXLtx-0002mS-TF for vdr@linuxtv.org; Thu, 06 Mar 2008 20:37:16 +0100 Received: from viper.bobcat.mine.nu (cs181065188.pp.htv.fi [82.181.65.188]) by smtp4.pp.htv.fi (Postfix) with ESMTP id 5649F5BC03E for <vdr@linuxtv.org>; Thu, 6 Mar 2008 21:37:10 +0200 (EET) From: Ville =?iso-8859-1?q?Skytt=E4?= <ville.skytta@iki.fi> To: vdr@linuxtv.org Date: Thu, 6 Mar 2008 21:37:09 +0200 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_lfE0HcMXOHyKp8l" Message-Id: <200803062137.09792.ville.skytta@iki.fi> X-LSpam-Score: 0.0 (/) Subject: [vdr] [PATCH] Use pkg-config to find freetype/fontconfig flags X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: VDR Mailing List <vdr@linuxtv.org> List-Id: VDR Mailing List <vdr.linuxtv.org> List-Unsubscribe: <http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>, <mailto:vdr-request@linuxtv.org?subject=unsubscribe> List-Archive: <http://www.linuxtv.org/pipermail/vdr> List-Post: <mailto:vdr@linuxtv.org> List-Help: <mailto:vdr-request@linuxtv.org?subject=help> List-Subscribe: <http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>, <mailto:vdr-request@linuxtv.org?subject=subscribe> X-List-Received-Date: Thu, 06 Mar 2008 19:37:16 -0000 Status: O X-Status: X-Keywords: X-UID: 16000 |
Commit Message
Ville Skyttä
March 6, 2008, 7:37 p.m. UTC
Hello, The attached patch makes VDR's Makefile use pkgconfig for finding libs and include dirs of freetype and fontconfig instead of making assumptions.
Comments
On 03/06/08 20:37, Ville Skyttä wrote: > Hello, > > The attached patch makes VDR's Makefile use pkgconfig for finding libs and > include dirs of freetype and fontconfig instead of making assumptions. How about putting that stuff at the same place everywhere? Why must it have to be somewhere else on every system? Klaus
En/na Klaus Schmidinger ha escrit: > On 03/06/08 20:37, Ville Skyttä wrote: >> Hello, >> >> The attached patch makes VDR's Makefile use pkgconfig for finding libs and >> include dirs of freetype and fontconfig instead of making assumptions. > > How about putting that stuff at the same place everywhere? > Why must it have to be somewhere else on every system? If you use packages provided by your linux distribution, usually include files are in /usr/include and libraries are in /usr/lib, while if you compile the source tarball yourself they go in /usr/local/include and /usr/local/lib or wherever you decide to put them (if, e.g., you're trying another version while you're keeping the old one, though I don't know if pkg-config will handle this case) Bye
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: <20080307114057.C44873@unqrf.nqzva.sez2> On Thu, 6 Mar 2008, Klaus Schmidinger wrote: > On 03/06/08 20:37, Ville Skyttä wrote: >> Hello, >> >> The attached patch makes VDR's Makefile use pkgconfig for finding libs and >> include dirs of freetype and fontconfig instead of making assumptions. > > How about putting that stuff at the same place everywhere? > Why must it have to be somewhere else on every system? Klaus, how about accepting the case, that the world has more than one Linux distribution and in addition, there is not only Linux where VDR can run on. How about beeing a little bit less ignorant when it comes to VDR and portability. What do you think why we have tools like pkg-config or autotools and so many projects make use of it? Because its funny? I don't think so! What's the big deal with Villa's proposal to change two lines in the Makefile when it breaks nothing for you and makes life easier for other users? Sorry for beeing harsh Joerg - -- The beginning is the most important part of the work. -Plato -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFH0TJeSPOsGF+KA+MRAsD1AKCdERUgFHIW444SvpkRvpwDrjsBcACdHCxz i82ezhk2fithcwziBJysTno= =jdQQ -----END PGP SIGNATURE-----
On 03/07/08 08:44, Luca Olivetti wrote: > En/na Klaus Schmidinger ha escrit: >> On 03/06/08 20:37, Ville Skyttä wrote: >>> Hello, >>> >>> The attached patch makes VDR's Makefile use pkgconfig for finding libs and >>> include dirs of freetype and fontconfig instead of making assumptions. >> How about putting that stuff at the same place everywhere? >> Why must it have to be somewhere else on every system? > > If you use packages provided by your linux distribution, usually include > files are in /usr/include and libraries are in /usr/lib, while if you > compile the source tarball yourself they go in /usr/local/include and > /usr/local/lib or wherever you decide to put them (if, e.g., you're > trying another version while you're keeping the old one, though I don't > know if pkg-config will handle this case) The root of the whole problem here IMHO is freetype2's weird way of handling its include files. I never understood why they had to use these strange macros for the includes. An application using freetype2 shouldn't have to add -I/usr/include/freetype2 to its include path. It should be possible to do #include <freetype2.h> and the rest should be handled inside that file. No weird macros, no extra include paths. BTW: whether an include file is in /usr/include or /usr/local/include doesn't matter - it is already found in both cases, without any extra effort. And the one in /usr/local/include takes precedence, just as one would ecpect. Klaus
On 03/07/08 13:17, Joerg Pulz wrote: > Content-ID: <20080307114057.C44873@unqrf.nqzva.sez2> > > On Thu, 6 Mar 2008, Klaus Schmidinger wrote: > >> On 03/06/08 20:37, Ville Skyttä wrote: >>> Hello, >>> >>> The attached patch makes VDR's Makefile use pkgconfig for finding >>> libs and >>> include dirs of freetype and fontconfig instead of making assumptions. > >> How about putting that stuff at the same place everywhere? >> Why must it have to be somewhere else on every system? > > Klaus, > > how about accepting the case, that the world has more than one Linux > distribution and in addition, there is not only Linux where VDR can run on. > How about beeing a little bit less ignorant when it comes to VDR and > portability. > What do you think why we have tools like pkg-config or autotools and so > many projects make use of it? Because its funny? I don't think so! > > What's the big deal with Villa's proposal to change two lines in the > Makefile when it breaks nothing for you and makes life easier for other > users? See my reply to Luca. Instead of having all applications work around freetyp2's weird include macro stuff, why not complain to the freetype2 people and have them provide just a plain old <freetype2.h> that can be included like any other header file? Sorry for being ignorant, but I have this tendency to try to solve problems at their root. Klaus
On Friday 07 March 2008, Klaus Schmidinger wrote: > Instead of having all applications work around freetyp2's weird include > macro stuff, why not complain to the freetype2 people and have them > provide just a plain old <freetype2.h> that can be included like any other > header file? > > Sorry for being ignorant, but I have this tendency to try to solve problems > at their root. FWIW, I think providing a pkgconfig file is very much a "root" solution (ditto $foo-config scripts, but *.pc are much simpler to write and read and have a unified interface). Lots of library packages (and also some others) provide them nowadays which is great, and has made the things you express dissatisfaction with in the above as well as other similar ones pretty much moot. In fact, I think VDR should also provide a *.pc file. I ship one in Fedora's VDR packages, and a good deal of it would be applicable to upstream VDR too. Just let me know if you're interested and I'll have a look at making a upstreamable version of it.
On 03/07/08 18:48, Ville Skyttä wrote: > On Friday 07 March 2008, Klaus Schmidinger wrote: > >> Instead of having all applications work around freetyp2's weird include >> macro stuff, why not complain to the freetype2 people and have them >> provide just a plain old <freetype2.h> that can be included like any other >> header file? >> >> Sorry for being ignorant, but I have this tendency to try to solve problems >> at their root. > > FWIW, I think providing a pkgconfig file is very much a "root" solution (ditto > $foo-config scripts, but *.pc are much simpler to write and read and have a > unified interface). Lots of library packages (and also some others) provide > them nowadays which is great, and has made the things you express > dissatisfaction with in the above as well as other similar ones pretty much > moot. > > In fact, I think VDR should also provide a *.pc file. I ship one in Fedora's > VDR packages, and a good deal of it would be applicable to upstream VDR too. > Just let me know if you're interested and I'll have a look at making a > upstreamable version of it. If this is as simple as putting another file into the VDR source directory (and leaving everything else as is), please send me that file and I'll take a look. Klaus
Ville Skyttä <ville.skytta@iki.fi> wrote: > FWIW, I think providing a pkgconfig file is very much a "root" > solution (ditto $foo-config scripts, but *.pc are much simpler to > write and read and have a unified interface). Lots of library > packages (and also some others) provide them nowadays which is great, > and has made the things you express dissatisfaction with in the above > as well as other similar ones pretty much moot. i can't agree more. > In fact, I think VDR should also provide a *.pc file. I ship one in > Fedora's VDR packages, and a good deal of it would be applicable to > upstream VDR too. Just let me know if you're interested and I'll have > a look at making a upstreamable version of it. i would even say VDR is broken in the way it handles plaugins. VDR's Makefile should install all exported vdr headers in $(PREFIX)/include/vdr and provide a vdr.pc file (as you suggest). then plugins could be buildable outside of VDR's source directory and install themself in $(PREFIX)/lib/vdr. as any other plugin capable program out there i know. just my 2 cents ... clemens
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 8 Mar 2008, Clemens Kirchgatterer wrote: > Ville Skyttä <ville.skytta@iki.fi> wrote: > >> FWIW, I think providing a pkgconfig file is very much a "root" >> solution (ditto $foo-config scripts, but *.pc are much simpler to >> write and read and have a unified interface). Lots of library >> packages (and also some others) provide them nowadays which is great, >> and has made the things you express dissatisfaction with in the above >> as well as other similar ones pretty much moot. > > i can't agree more. > >> In fact, I think VDR should also provide a *.pc file. I ship one in >> Fedora's VDR packages, and a good deal of it would be applicable to >> upstream VDR too. Just let me know if you're interested and I'll have >> a look at making a upstreamable version of it. > > i would even say VDR is broken in the way it handles plaugins. VDR's > Makefile should install all exported vdr headers in > $(PREFIX)/include/vdr and provide a vdr.pc file (as you suggest). then > plugins could be buildable outside of VDR's source directory and > install themself in $(PREFIX)/lib/vdr. as any other plugin capable > program out there i know. > > just my 2 cents ... > clemens Clemens, you are so damn right! +1 from my side Joerg - -- The beginning is the most important part of the work. -Plato -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFH0nFxSPOsGF+KA+MRArb3AKCG5dH73MNsSs53yspji2hV/v8zDwCgte11 CpaEgzbmHUsy7THwZgUQpa4= =lClI -----END PGP SIGNATURE-----
On 03/08/08 11:54, Clemens Kirchgatterer wrote: > Ville Skyttä <ville.skytta@iki.fi> wrote: > >> FWIW, I think providing a pkgconfig file is very much a "root" >> solution (ditto $foo-config scripts, but *.pc are much simpler to >> write and read and have a unified interface). Lots of library >> packages (and also some others) provide them nowadays which is great, >> and has made the things you express dissatisfaction with in the above >> as well as other similar ones pretty much moot. > > i can't agree more. > >> In fact, I think VDR should also provide a *.pc file. I ship one in >> Fedora's VDR packages, and a good deal of it would be applicable to >> upstream VDR too. Just let me know if you're interested and I'll have >> a look at making a upstreamable version of it. > > i would even say VDR is broken in the way it handles plaugins. VDR's > Makefile should install all exported vdr headers in > $(PREFIX)/include/vdr and provide a vdr.pc file (as you suggest). then > plugins could be buildable outside of VDR's source directory and > install themself in $(PREFIX)/lib/vdr. as any other plugin capable > program out there i know. I don't care what the "install" targets actually do, since I dont use them. So if you want to change that, suggest a patch. However, it must still be possible to build and run plugins in VDR/PLUGINS/... as it is right now (without using "install-plugins"). Klaus
Joerg Pulz wrote: > What do you think why we have tools like pkg-config or autotools and so > many projects make use of it? Because its funny? I don't think so! > > What's the big deal with Villa's proposal to change two lines in the > Makefile when it breaks nothing for you and makes life easier for other > users? #>pkg-config --libs freetype2 fontconfig -bash: pkg-config: command not found - no comment - Cheers, Udo
Udo Richter <udo_richter@gmx.de> wrote: > #>pkg-config --libs freetype2 fontconfig > -bash: pkg-config: command not found > > - no comment - i could as easily argue with: > make bash: make: command not found pkg-config is no exotic dependency that we have good reason to avoid. clemens
Clemens Kirchgatterer wrote:
> pkg-config is no exotic dependency that we have good reason to avoid.
I know that its easy to install that package. (Though I wonder whether
the linvdr guys agree.)
My point is just that its not a change-one-line-and-all-will-be-happy,
it does add one more to the build dependency.
Basically we have two options here:
1 - keep a hard coded include path. That way some people would need to
set up additional include paths manually.
2 - Use pkg-config. This way some people would need to install
pkg-config to build VDR.
The question is: Which way would spoil more people? At least for me
(s/me/Debian/), the default paths seem to be just fine. So I wonder: How
many people need to set up different include paths?
Or even better: Is there a third way that works for both?
Cheers,
Udo
Udo Richter <udo_richter@gmx.de> wrote:
> Or even better: Is there a third way that works for both?
as i have written in my RFC there is:
freetype-config
On 03/08/08 17:43, Udo Richter wrote: > Clemens Kirchgatterer wrote: >> pkg-config is no exotic dependency that we have good reason to avoid. > > I know that its easy to install that package. (Though I wonder whether > the linvdr guys agree.) > My point is just that its not a change-one-line-and-all-will-be-happy, > it does add one more to the build dependency. > > Basically we have two options here: > 1 - keep a hard coded include path. That way some people would need to > set up additional include paths manually. > 2 - Use pkg-config. This way some people would need to install > pkg-config to build VDR. > > The question is: Which way would spoil more people? At least for me > (s/me/Debian/), the default paths seem to be just fine. So I wonder: How > many people need to set up different include paths? > > Or even better: Is there a third way that works for both? I'll add a section to the Make.config file for "packages with non-default locations", like INCLUDES += -I/usr/include/freetype2 Then everybody can overwrite that in whatever way fits their needs. I still believe, though, that freetype2's include files are broken. A simple '#include <freetype2.h>' should be enough. If their header file(s) would behave like the rest, we wouldn't have this discussion. Klaus
On 03/08/08 15:01, Clemens Kirchgatterer wrote: > Udo Richter <udo_richter@gmx.de> wrote: > >> #>pkg-config --libs freetype2 fontconfig >> -bash: pkg-config: command not found >> >> - no comment - > > i could as easily argue with: > >> make > bash: make: command not found How do you build VDR without 'make'? Klaus
Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de> wrote: > On 03/08/08 15:01, Clemens Kirchgatterer wrote: > > Udo Richter <udo_richter@gmx.de> wrote: > > > >> #>pkg-config --libs freetype2 fontconfig > >> -bash: pkg-config: command not found > >> > >> - no comment - > > > > i could as easily argue with: > > > >> make > > bash: make: command not found > > How do you build VDR without 'make'? my point was, that even make is no strict requiremant for building vdr, we could have a shell script as well or call gcc by hand. of course make makes life easier, so we use it. but so does pkg-config.
Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de> wrote: > I still believe, though, that freetype2's include files are broken. > A simple '#include <freetype2.h>' should be enough. If their header > file(s) would behave like the rest, we wouldn't have this discussion. no. pkg-config and freetype-config have absolutly nothing to do with that. i think nearly every "obtional" library has one of these to provide a way to find them at compile and link time. please see the output of: ls /usr/bin/*-config clemens
On 03/08/08 19:12, Clemens Kirchgatterer wrote: > Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de> wrote: > >> I still believe, though, that freetype2's include files are broken. >> A simple '#include <freetype2.h>' should be enough. If their header >> file(s) would behave like the rest, we wouldn't have this discussion. > > no. pkg-config and freetype-config have absolutly nothing to do with > that. i think nearly every "obtional" library has one of these to > provide a way to find them at compile and link time. please see the > output of: ls /usr/bin/*-config But would it kill anybody to simply have all header files at a standard place (/usr/include and /usr/local/include)? Why should every application go on a scavenger hunt to find all the header files it needs? Anyway, it's going to be in Make.config, then you can do whatever you like ;-) Klaus
Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de> wrote: > On 03/08/08 19:12, Clemens Kirchgatterer wrote: > > Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de> wrote: > > > >> I still believe, though, that freetype2's include files are broken. > >> A simple '#include <freetype2.h>' should be enough. If their header > >> file(s) would behave like the rest, we wouldn't have this > >> discussion. > > > > no. pkg-config and freetype-config have absolutly nothing to do with > > that. i think nearly every "obtional" library has one of these to > > provide a way to find them at compile and link time. please see the > > output of: ls /usr/bin/*-config > > But would it kill anybody to simply have all header files at > a standard place (/usr/include and /usr/local/include)? yes it would. how would you install different versions of the same libraries (with their headers) if it wasn't in different paths? and what about cross compilers? the possibillity of having libs and headers in different places is a very important feature, not an anoying bug. > Why should every application go on a scavenger hunt to find > all the header files it needs? see above. anyway, thats the way it was since many many years for good reasons. it's the standard way of finding compiler and linker flags for libraries and you like obeying standards, don't you? SCNR... clemens
Clemens Kirchgatterer wrote: >> But would it kill anybody to simply have all header files at >> a standard place (/usr/include and /usr/local/include)? > > yes it would. how would you install different versions of the same > libraries (with their headers) if it wasn't in different paths? and > what about cross compilers? the possibillity of having libs and headers > in different places is a very important feature, not an anoying bug. Using different versions of a library or cross-compiling will always require manual setup of include paths anyway. How should any magic configuration tool know which of the installed headers should be used anyway? There is _one_ currently installed default version of the headers for this machine, and the question is why these headers are not at a default location, esp. since the binaries seem to be at a default location, or? (btw. in case I do have two sets of include files and I need to switch between them: Changing an INCLUDE= is pretty obvious, but how do I tell pkg-config or freetype-config what I want to compile?) Cheers, Udo
On Sat, 2008-03-08 at 19:12 +0100, Clemens Kirchgatterer wrote: > Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de> wrote: > > > I still believe, though, that freetype2's include files are broken. > > A simple '#include <freetype2.h>' should be enough. If their header > > file(s) would behave like the rest, we wouldn't have this discussion. > > no. pkg-config and freetype-config have absolutly nothing to do with > that. i think nearly every "obtional" library has one of these to > provide a way to find them at compile and link time. please see the > output of: ls /usr/bin/*-config I don't know make's syntax, but why not do something like: in shell: $(freetype-config 2>/dev/null --cflags || echo /usr/include/freetype3) As I said I don't know make's config but it might be: $(shell freetype-config 2>/dev/null --cflags || echo /usr/include/freetype3) > clemens > > _______________________________________________ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr >
On Sun, Mar 9, 2008 at 10:50 AM, Udo Richter <udo_richter@gmx.de> wrote: > There is _one_ currently installed default version of the headers for > this machine, and the question is why these headers are not at a default > location, esp. since the binaries seem to be at a default location, or? no, think about having two versions of the same library stack in for example /opt1 and /opt2. both prefixes contain the usual directory 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. > (btw. in case I do have two sets of include files and I need to switch > between them: Changing an INCLUDE= is pretty obvious, but how do I tell > pkg-config or freetype-config what I want to compile?) see above. as each version of the libraries is compiled with different prefixes (and maybe even with different dependencies) they come with their very own *.pc or *-config file. to switch between them at compile time, i simply have to manypulate PKG_CONFIG_PATH (or PATH in case of *-config) and at runtime i have to fix the linker path with LD_LIBRARY_PATH. there is another argument for pkg-config we havent talked about yet. the link dependencies. type 'freetype-config --libs' and it will most likly print '-lfreetype -lz' but only if you have compiled freetype with zlib support. or another dependency vdr does not handle properly: ncurses. on my system 'ncurses5-config --cflags --libs' prints -L/usr/lib -lncurses -ldl -I/usr/include/ncurses, but it could as easily be somewhere else. best regards ... clemens
Hi, Am Montag, den 10.03.2008, 11:39 +0100 schrieb clemens kirchgatterer: > there is another argument for pkg-config we havent talked about yet. > the link dependencies. type 'freetype-config --libs' and it will most > likly print '-lfreetype -lz' but only if you have compiled freetype > with zlib support. or another dependency vdr does not handle properly That the point, for the plugin vdr-image[¹] exist same problems with libavcodec from ffmpeg. This library has many compile options. I thick the best solution are "pkg-config" to handle includes and libraries dependencies in a proper style. Andreas My sample with libavcodec and optionally libswscale and libexif [¹] http://svn.berlios.de/svnroot/repos/vdr-image/trunk/Makefile
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? 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? Btw. do I need to call /opt1/usr/bin/freetype-config? or will any freetype-config be ok? Cheers, Udo
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.
On Mon, Mar 10, 2008 at 7:31 PM, Udo Richter <udo_richter@gmx.de> 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? yes it is, because 1. pkg-config will handle the linker flags as well (otherwise you will have to give gcc the correct -L/opt1/usr/lib path), an 2. dealing with pkg-config is the standard way of doing this kind of things. > 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 should the libraries (and their headers) be installed in the default search path in the first place? > Btw. do I need to call /opt1/usr/bin/freetype-config? or will any > freetype-config be ok? /opt1/usr/bin/freetype-config thats one of the reasons why pkg-config is prefered. it has a distinctiv $PKG_CONFIG_PATH and does not depend on $PATH. geetings ... clemens
--- Makefile~ 2008-02-29 23:43:03.000000000 +0200 +++ Makefile 2008-03-06 21:29:58.000000000 +0200 @@ -20,8 +20,8 @@ MANDIR = $(PREFIX)/share/man BINDIR = $(PREFIX)/bin LOCDIR = ./locale -LIBS = -ljpeg -lpthread -ldl -lcap -lrt -lfreetype -lfontconfig -INCLUDES = -I/usr/include/freetype2 +LIBS = -ljpeg -lpthread -ldl -lcap -lrt $(shell pkg-config --libs freetype2 fontconfig) +INCLUDES = $(shell pkg-config --cflags-only-I freetype2 fontconfig) PLUGINDIR= ./PLUGINS PLUGINLIBDIR= $(PLUGINDIR)/lib