View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0014601CMakeCMakepublic2013-11-27 10:442016-06-10 14:31
ReporterRyan Schmidt 
Assigned ToKitware Robot 
Platformx86_64OSOS XOS Version10.9
Product VersionCMake 2.8.12 
Target VersionFixed in Version 
Summary0014601: FindFreetype.cmake doesn't work with freetype 2.5.1
DescriptionAfter updating freetype in MacPorts to 2.5.1, cmake is unable to find freetype using FindFreetype.cmake. This was reported to MacPorts here: [^]

The problem seems to be that it's looking for ${FREETYPE_INCLUDE_DIR_freetype2}/freetype/freetype.h, and as of freetype 2.5.1, that's not where that file is located anymore.
Steps To ReproduceThe freetype CHANGES file says:

    - The header file layout has been changed. After installation,
      all files are now located in `<prefix>/include/freetype2'.

      Applications that use (a) `freetype-config' or FreeType's
      `pkg-config' file to get the include directory for the compiler,
      and (b) the documented way for header inclusion like

        #include <ft2build.h>
        #include FT_FREETYPE_H

      don't need any change to the source code.

So evidently FindFreetype isn't using those methods; I found your bug report 0013959 requesting those methods be used. It's now urgent that this be done.
TagsNo tags attached.
Attached Filespatch file icon findfreetype.patch [^] (996 bytes) 2013-12-01 19:25 [Show Content]
patch file icon cmake- [^] (1,400 bytes) 2013-12-08 09:12 [Show Content]
patch file icon 2-cmake- [^] (1,388 bytes) 2013-12-08 13:59 [Show Content]

related to 0013959closedKitware Robot FindFreetype.cmake does not have a fallback (like pkgconfig or freetype-config) 
related to 0014626closedKitware Robot FindFreetype module needs a new maintainer and an overhaul 

Brad King (manager)
2013-11-27 11:13 [^]
Sven-Hendrik Haase (reporter)
2013-12-01 19:27

I made a backwards compatible patch that should resolve this issue.
Ryan Schmidt (reporter)
2013-12-01 20:56

That patch doesn't look right to me at all. You've added include/freetype to the paths. No such directory exists, either with freetype 2.5.0 or with 2.5.1.

The change made in freetype 2.5.1 is that files that were formerly in include/freetype2/freetype/ are now in include/freetype2/. You're never meant to refer to those files by their pathnames; you're meant to refer to them via the #defines in the ftheader.h file.

The whole methodology used in FindFreetype.cmake is flawed. There's already a lengthy comment in that file acknowledging that:

# Ugh, FreeType seems to use some #include trickery which
# makes this harder than it should be. It looks like they
# put ft2build.h in a common/easier-to-find location which
# then contains a #include to a more specific header in a
# more specific location (#include <freetype/config/ftheader.h>).
# Then from there, they need to set a bunch of #define's
# so you can do something like:
# #include FT_FREETYPE_H
# Unfortunately, using CMake's mechanisms like include_directories()
# wants explicit full paths and this trickery doesn't work too well.
# I'm going to attempt to cut out the middleman and hope
# everything still works.

This hack of "cutting out the middleman and hoping everything still works" doesn't work anymore.

All you need to do to find freetype is to ask pkg-config (or freetype-config) where it is and what cflags and ldflags to use; remove the code that tries to guess where it is.
Brad King (manager)
2013-12-02 09:01

Re 0014601:0034621: Is "0001-Support-finding-freetype2-using-pkg-config.patch" in 0013959 sufficient?

My link in 0014601:0034591 is an invitation for additional module maintainers to volunteer to help out with this module.
Brad King (manager)
2013-12-03 13:13

The FindFreetype.cmake module needs a new volunteer maintainer and a major overhaul: [^]

Moving this issue to the backlog until that happens.
Ryan Schmidt (reporter)
2013-12-03 23:25

No, that patch is not sufficient because of the line:

 find_path(FREETYPE_INCLUDE_DIR_freetype2 freetype/config/ftheader.h

and the subsequent lines referencing FREETYPE_INCLUDE_DIR_freetype2. In freetype 2.5.1, the relative path freetype/config/ftheader.h has changed (the "freetype" directory has been deleted). In general, the location of ftheader.h and the other headers formerly in the "freetype" directory is an implementation detail that configuration scripts should not attempt to determine. Even in older versions of freetype, this location can be changed at configuration time.
Julian Ospald (reporter)
2013-12-08 09:13

cmake- works for me and also correctly identifies the freetype version and still works with old freetype
Ryan Schmidt (reporter)
2013-12-08 09:21

That patch doesn't look right to me either.
Julian Ospald (reporter)
2013-12-08 12:39

Then explain what does not look right. I cannot help with such vague statements.
Ryan Schmidt (reporter)
2013-12-08 13:00

Sorry about that, but I was already more specific in a previous comment above. I just don't understand why there needs to be a 100-line script to check for the existence of various files in various directories, when none of that should be of any relevance to cmake. All cmake should need to know is what include directories and libraries to use, and the correct way to find that out is to run `freetype-config` or `pkg-config freetype` and use the flags it gives you. This will insulate cmake from future changes.
Julian Ospald (reporter)
2013-12-08 13:21

you have probably missed our ignored bug report here [^]
Ryan Schmidt (reporter)
2013-12-08 13:35

No, I've seen it, and explained above why the patch attached there doesn't work without further changes.
Julian Ospald (reporter)
2013-12-08 13:42

I was referring to the fact that cmake upstream does not care about pkg-config or other means to correctly get cflags/libs.

Because of that a lot of cmake code across many projects rely on the current way of passing include-dir rather than the actual flags. The needed adjustment to the pkg-config patch is exactly what I just attached here.

Other ways to use pkg-config _correctly_ do not work with the current module logic. And this is a fact for almost all cmake modules. So I am not sure what you are trying to say here.
Julian Ospald (reporter)
2013-12-08 14:00

although the previous patch worked for me, the include-dir did not match the one reported by pkg-config

2-cmake- fixes that, thanks to Rafał Mużyło
Brad King (manager)
2013-12-09 09:21

As stated in 0014601:0034696 and in issue 0014626 no upstream progress will be made on the FindFreetype module until a volunteer steps forward to become its maintainer. CMake core developers cannot possibly keep track of everything that happens in all find-able third-party packages. We depend on volunteers with expertise in each package. The FindFreetype module was contributed and the original contributor no longer actively participates. Therefore we need a new volunteer.
Brad King (manager)
2013-12-09 09:33

Re 0014601:0034753: CMake cannot simply take pkg-config's flags and pass them through directly to compile and link lines. There are a few reasons for this. Among them are:

1. CMake Find modules have to work on Windows with MSVC and other tools that pkg-config does not support.

2. Raw -L/-l flag pairs do not work reliably when using many libraries from different paths on the system that may conflict with one another in required -L search order. Therefore we need to find the full path to each library needed.

3. CMake needs higher-level information than just the raw flags so that it can map the package usage requirements to other formats such as IDE project files.

The proper way to use pkg-config with CMake is to teach each find module to run it as a way of learning where to look for the files needed, and then passing those as the HINTS option to find_* commands. Of course the other flags besides -I, -L, and -l need to be collected and reported in other result variables too.

This discussion is out of scope for this issue tracker entry and would better be raised on the mailing list.
Kitware Robot (administrator)
2016-06-10 14:29

Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

 Issue History
Date Modified Username Field Change
2013-11-27 10:44 Ryan Schmidt New Issue
2013-11-27 11:09 Brad King Relationship added related to 0013959
2013-11-27 11:11 Brad King Assigned To => Eric Wing
2013-11-27 11:11 Brad King Status new => assigned
2013-11-27 11:13 Brad King Note Added: 0034591
2013-12-01 19:25 Sven-Hendrik Haase File Added: findfreetype.patch
2013-12-01 19:27 Sven-Hendrik Haase Note Added: 0034620
2013-12-01 20:56 Ryan Schmidt Note Added: 0034621
2013-12-02 09:01 Brad King Note Added: 0034662
2013-12-03 13:13 Brad King Note Added: 0034696
2013-12-03 13:13 Brad King Assigned To Eric Wing =>
2013-12-03 13:13 Brad King Status assigned => backlog
2013-12-03 13:16 Brad King Relationship added related to 0014626
2013-12-03 23:25 Ryan Schmidt Note Added: 0034703
2013-12-08 09:12 Julian Ospald File Added: cmake-
2013-12-08 09:13 Julian Ospald Note Added: 0034747
2013-12-08 09:21 Ryan Schmidt Note Added: 0034748
2013-12-08 12:39 Julian Ospald Note Added: 0034749
2013-12-08 13:00 Ryan Schmidt Note Added: 0034750
2013-12-08 13:21 Julian Ospald Note Added: 0034751
2013-12-08 13:35 Ryan Schmidt Note Added: 0034752
2013-12-08 13:42 Julian Ospald Note Added: 0034753
2013-12-08 13:59 Julian Ospald File Added: 2-cmake-
2013-12-08 14:00 Julian Ospald Note Added: 0034754
2013-12-09 09:21 Brad King Note Added: 0034757
2013-12-09 09:33 Brad King Note Added: 0034758
2016-06-10 14:29 Kitware Robot Note Added: 0042435
2016-06-10 14:29 Kitware Robot Status backlog => resolved
2016-06-10 14:29 Kitware Robot Resolution open => moved
2016-06-10 14:29 Kitware Robot Assigned To => Kitware Robot
2016-06-10 14:31 Kitware Robot Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team