Re: [Freetype]2.0 release install problems on Unix systems

[David Turner]

Hi Stefan,

> 
> I understand the problem of conflicting headers. And I think a perfect 
> solution is to
> let the user decide where to install freetype(2). That should of course be 
> reflected
> by freetype-config.
>
If the user only uses "freetype-config" appropriately, it doesn't need to
even worry about the location, and can already choose to install it where
it wants.

We could add a switch to the configure script to disable the 
"freetype2/freetype"
trick (in this case, the library headers would be installed in 
$(prefix)/include/freetype
as yesterday).

What's important is to never assume this location for obvious portability 
reasons..
Always use "freetype-config", even if you disabled the "freetype2/freetype" 
trick,
this will keep your program portable among different installations..

> That being said, I don't see a need for the subdirectory 'freetype2'. Either, 
> the user
> already uses an older freetype version, at which point he could just install 
> freetype2
> elsewhere, or he does not, than it doesn't matter anyway. May be the Makefile 
> could check
> for an existing freetype installation and warn about it. I'd guess that not 
> many people
> will use both versions anyway...
>
The FT2 Makefile could check for a FT1 installation. The FT1 Makefile will not
check for a FT2 installation .. :-(

> Of course, there is still a theoretical problem, which appears if you'd need 
> to work with
> both versions in the same project, i.e. you'd need be sure that the 
> preprocessor chooses
> the right '-I' statement for the right file. But that seems purely 
> academical, as no-one will
> ever use freetype 1 and freetype 2 in the same project.
> 
I'm pretty certain that the conflict is _not_ academical, given that one of my
colleagues ran into it today when trying to install the library on its system
and compile a bunch of various utilities..

You need distinct directories, and FT1 is hard-coded to "freetype"

> Regards, Stefan
> 
> PS: for binary packages, I'd suggest to pay attention that they are 
> relocatable (rpm, deb),
>     to avoid aforementioned conflict.
> 
That's an excellent suggestion. Unfortunately, I'm not knowledgeable in the
package management fields. I'd appreciate if someone could provide some
spec files ??

Regards,

- David