[cmake-developers] FindFreetype Maintenance

Brad King brad.king at kitware.com
Fri May 23 09:31:35 EDT 2014


On Fri, May 23, 2014 at 12:56 AM, Greg Jung <gvjung at gmail.com> wrote:
> Somehow $ENV{CFLAGS} impossibly translates the first group but fails to go
> beyond that first blank.

The *only* program that translates paths in MinGW is the MSYS shell.
When it passes command line arguments and environment variables to
programs not located inside one of its soft mounts, it tries to
convert paths to pure windows paths.  In your example the value of
CFLAGS has been changed by the shell before CMake even runs.

For example, try:

 $ CFLAGS='-I/usr/local/include -I/usr/include' cmd //c echo %CFLAGS%
 -IC:/MinGW/msys/1.0/local/include -I/usr/include

Certainly "cmd" and "echo" are not doing that conversion.

> Including /usr and /usr/local in the .cmake file's search would solve the
> unix problem.

They shouldn't be needed explicitly in the module at all.  See my
response to Taylor's first patch.

> It doesn't make sense to me to chase every different freetype install
> location.

Agreed.  The current module's guesses need to be preserved for compatibility
(if they are not otherwise searched already), but should not be used as an
example of how to do it.

> It does make sense to reform
> the original kludge, which finds ft2build.h (should be easy) then goes after
> config/ftheader.h; ft2build simply
> includes (???)/config/ftheader.h  in whatever the way it would show.
> A simple search for freetype as a library, then verifying the affiliated
> include directory for ft2build.h,
> should replace the gymnastics there now.

Searching for ft2build.h is correct because that is the header that
applications are expected to include directly.  The rest of the
search is an attempt to locate the real headers so the version
can be extracted, AFAICT.

-Brad



More information about the cmake-developers mailing list