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

Volker Simonis volker.simonis at gmail.com
Tue Sep 9 17:21:01 UTC 2014

On Tue, Sep 9, 2014 at 2:38 PM, Magnus Ihse Bursie
<magnus.ihse.bursie at oracle.com> wrote:
> Hi Volker,
> Sorry for not responding to this earlier.

No problem..

> As I said in the bug, I really like this idea!
> I have a few comments.
> I understand why you would have liked to add the ac_executable_extensions
> stuff, but since you can't due to performance, and that is not likely to
> change in the future either, the extra commented-out code in platform.m4
> serves no purpose and should be removed.

It was just because it took me so long to find this out because
'ac_executable_extensions' doesn't seem to be documented anywhere. But
your're right, it's probably not the right place to document it. So I

+  # Setting 'ac_executable_extensions' on Windows may be necessary if
there's a directory with the same name like
+  # an executable without it's extension (i.e. the .NET framework
directory contains the subdirectory 'msbuild' and
+  # the executable 'msbuild.exe'. The AC_CHECK_PROG macros won't find
'msbuild' without setting 'ac_executable_extensions'.
+  # The drawback of setting 'ac_executable_extensions' is that it
will slow down all the program checks because the
+  # AC_CHECK_PROG macros will always for all the extensions. Therefor
we leave the code below commented out for now
+  # and simply check for 'msbuild.exe' in
+  #
+  #case "${build_os}" in
+  #  cygwin|msys)
+  #    ac_executable_extensions=".exe .com .bat .cmd"
+  #  ;;
+  #  *)
+  #  ;;
+  #esac

..and only repasted it here such that it can be easily googled in the
future and forever :)

> The description when locating msbuild is enough I think, maybe rewritten
> like this:
> # We need to check for 'msbuild.exe' because at the place where we expect to
> # find 'msbuild.exe' there's also a directory called 'msbuild' and configure
> # won't find the 'msbuild.exe' executable in that case (and
> # 'ac_executable_extensions' is unusable due to performance reasons).


> However, I'm thinking if maybe the check for msbuild.exe should move to
> toolchain_windows.m4, maybe at the end of TOOLCHAIN_SETUP_VISUAL_STUDIO_ENV.
> It's a bit extra messy (like you don't normalize the path), and it's part of
> the microsoft build tool chain mess. :-) If so, you can use the fact that
> the msbuild.exe you want to use is located in VS_PATH, and use that as
> search path to AC_CHECK_PROG. Or maybe that's not useful, I dunno. I'm not
> 100% sure about this though, so if you think it's better were it is, leave
> it.

As you wrote, TOOLCHAIN_SETUP_VISUAL_STUDIO_ENV is already quite big
and complex. I'd prefer to leave it where it is.

Conceptually you're right that it would belong to toolchain_windows.m4
and that's where I wanted to add it first. But then I checked where
other Windows tools are detected and saw that we already have this
"x$TOOLCHAIN_TYPE" = xmicrosoft; section in the generic toolchain.m4
file anyway. So I think it's a good place to leave it there.

> Also, I'm not entirely happy on the complexity of the freetype detection
> code. It's a beast. :-/ It's not your fault, and I'm not sure what do to
> counter that, but at least I think it would help if you could extract the
> relevant part of your new compilation code into a separate function so we at
> least try to keep it from growing further (remember that it need to be
> AC_DEFUN and not AC_DEFUN_ONCE in that case).

You're right! I extracted most of the build logic into its own
function "LIB_BUILD_FREETYPE". I think it's much cleaner and more
robust now.

> I must compliment you on the well-designed feedback to the user about
> possible errors and what to do about them! I really like that.


> Apart from this minor issues, your code looks good. (For the records, I have
> read the code but not tested it.)

I've tested on Linux and on Windows both 32- and 64-bit builds with
Cygwin and MinGW/MSYS

Here's  the new version:


And as I wrote, I need a sponsor because of generated-configure.sh...

Thank you and best regards,

> /Magnus

More information about the build-dev mailing list