Use pkg-config to find freetype/fontconfig flags

  Hello,

The attached patch makes VDR's Makefile use pkgconfig for finding libs and 
include dirs of freetype and fontconfig instead of making assumptions.
  

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