RFR: JDK-8001922, JDK-8001927, JDK-8001921 Improve freetype detection

[Magnus Ihse Bursie]

Comments inline.

18 okt 2013 kl. 15:22 skrev Erik Joelsson <erik.joelsson at oracle.com>:

> 
> On 2013-10-18 14:59, Magnus Ihse Bursie wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8001922
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8001927
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8001921
>> 
>> These three bugs are all tightly related. The logic for detecting the freetype library has been really messy, and these were three of the ways the deficiencies showed themselves, but they were all resulting from the core problem.
>> 
>> I have redesigned the way freetype detection work, to be more in line with the normal way we detect "problematic" stuff in configure, that is, probe in suitable locations with decreasing precision, and check thouroughly what we find. (In this case, by compiling with the header files and linking with the library).
>> 
>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8001922-improve-freetype-detection/webrev.01
>> 
>> /Magnus
> Typo: "only one"
> 372         # User specified only on of lib or include. This is an error.

Thanks!

> 
> A question on Windows. If we find freetype in $PROGRAMFILES/GnuWin32, will the resulting jdk image find the library there at runtime or should we still bundle it?

This will be the same as before my fix: it will not be copied, since USING_SYSTEM_FT_LIB will be true. (This variable basically means: don't bundle freetype). It will only be false (i.e. freetype will be bundled) if we explicitely set --with-freetype. As it was before. *)

I'm not sure this logic is sane. Arguably, we should have a separate option: --enable-freetype-bundling, or something like that.

*) Actually, when I scrutinized the code, I noticed that USING_SYSTEM_FT_LIB was incorrectly set when using builddeps or pkg-config. I'll update the WebRe regarding this and the typo.

/Magnus