RFR(M): 8057538: Build the freetype library during configure on Windows

[Volker Simonis]

On Fri, Sep 5, 2014 at 12:31 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> Hello Volker,
>
> This is certainly an interesting proposition.
>
> The grep for "SDKs" as test wasn't enough for Visual Studio 2010 as we have
> an SDK directory then too, containing "v7.0A". I changed it to the below to
> make it work for me, but I'm not sure it's a good enough test. Magnus will
> likely have an opinion on this.
>
> if $ECHO "$VS_PATH" | grep -q 'Microsoft Visual Studio 10.0'; then
>   freetype_platform_toolset=""
> elif $ECHO "$VS_PATH" | grep -q 'SDKs'; then
>   freetype_platform_toolset="/p:PlatformToolset=Windows7.1SDK"
> fi
>

I see. This seems to be much trickier than I thought. Unfortunately
'Microsoft Visual Studio 10.0' is also in the path if we have a
SDK-only installation:)

So if Magnus doesn't come up with a better idea maybe we have to
remember the toolset in a variable right during the detection process?

But apart from that - did it work for you?

Thank you and best regards,
Volker

> /Erik
>
>
> On 2014-09-04 18:59, Volker Simonis wrote:
>>
>> Hi,
>>
>> could you please have a look at the following change which makes it
>> possible to build the freetype libraries during the configure step
>> from the plain freetype sources on Windows:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/8057538/
>> https://bugs.openjdk.java.net/browse/JDK-8057538
>>
>> The fact that there are no standard binary packages of freetype
>> available on windows is one of the few remaining annoyances when
>> building the OpenJDK on Windows.
>>
>> It turns out however, that it is relatively simply and needs just a
>> few seconds to build the required libraries from the freetype source
>> ball during the configure process. The only extra dependency which is
>> required is 'msbuild.exe' which comes with the .NET 4.0 installation
>> and as far as I could see, probably most of the Windows boxes will
>> have that anyway.
>>
>> This change will introduce a new configure option
>> "--with-freetype-src" which builds the required freetype libraries
>> into <freetype_src>/lib[32|64] and sets "--with-freetype-lib" and
>> "--with-freetype-include" automatically.
>>
>> Later builds can than simple use
>> "--with-freetype-lib=<freetype_src>/lib[32|64]" and
>> "--with-freetype-include=<freetype_src>/include".
>>
>> If this new option is used, the build results will be available in
>> ./freetype.log
>>
>> Notice that I intentionally build the libraries into the freetype
>> source directory. On the one hand it's considered bad style to pollute
>> the source directory, on the other hand, we'll only have to do this
>> two times (once for a 32- and once for a 64-bit build) and use the
>> created libraries for all other builds later on.
>>
>> I've tested this on a 64-bit Windows 7 box with both Cygwin and
>> MingGW/MSYS building both, 32- and 64-bit versions of the OpenJDK.
>> However I only tested with a vanilla SDK 7.1 installation. I think the
>> build should also work with a VS2010 installation, but I'd need
>> sombody to test it. If it should not work, I think it can be easily
>> fixed in common/autoconf/libraries.m4 by inserting the corresponding
>> toolset identifiers as described by this comment:
>>
>>            # The original freetype project file is for VS 2010 (i.e.
>> 'v100'), so we have to adapt the toolset if building with the SDK
>>            # TODO: we may also have to set the toolset to 'v110' or
>> 'v120' if building with VS 2012 or VS2013 respectively
>>            # TODO: find a better (more reliable) test for the actual,
>> active toolset
>>            if $ECHO "$VS_PATH" | grep -q 'SDKs'; then
>>              freetype_platform_toolset="/p:PlatformToolset=Windows7.1SDK"
>>            fi
>>
>> Thank you and best regards,
>> Volker
>
>