(0034591)
Brad King (manager)
2013-11-27 11:13

http://www.cmake.org/Wiki/CMake:Module_Maintainers [^]

(0034620)
Sven-Hendrik Haase (reporter)
2013-12-01 19:27

I made a backwards compatible patch that should resolve this issue.

(0034621)
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.

(0034662)
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.

(0034696)
Brad King (manager)
2013-12-03 13:13

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

http://www.cmake.org/Wiki/CMake:Module_Maintainers [^]

Moving this issue to the backlog until that happens.

(0034703)
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.

(0034747)
Julian Ospald (reporter)
2013-12-08 09:13

cmake-2.8.11.2-FindFreetype.patch works for me and also correctly identifies the freetype version and still works with old freetype

(0034748)
Ryan Schmidt (reporter)
2013-12-08 09:21

That patch doesn't look right to me either.

(0034749)
Julian Ospald (reporter)
2013-12-08 12:39

Then explain what does not look right. I cannot help with such vague statements.

(0034750)
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.

(0034751)
Julian Ospald (reporter)
2013-12-08 13:21

you have probably missed our ignored bug report here http://www.cmake.org/Bug/view.php?id=13959 [^]

(0034752)
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.

(0034753)
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.

(0034754)
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-2.8.11.2-FindFreetype.patch fixes that, thanks to Rafał Mużyło

(0034757)
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.

(0034758)
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.

(0042435)
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-2.8.11.2-FindFreetype.patch
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-2.8.11.2-FindFreetype.patch
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

Notes
(0034591) Brad King (manager) 2013-11-27 11:13	http://www.cmake.org/Wiki/CMake:Module_Maintainers [^]

(0034620) Sven-Hendrik Haase (reporter) 2013-12-01 19:27	I made a backwards compatible patch that should resolve this issue.

(0034621) 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.

(0034662) 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.

(0034696) Brad King (manager) 2013-12-03 13:13	The FindFreetype.cmake module needs a new volunteer maintainer and a major overhaul: http://www.cmake.org/Wiki/CMake:Module_Maintainers [^] Moving this issue to the backlog until that happens.

(0034703) 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.

(0034747) Julian Ospald (reporter) 2013-12-08 09:13	cmake-2.8.11.2-FindFreetype.patch works for me and also correctly identifies the freetype version and still works with old freetype

(0034748) Ryan Schmidt (reporter) 2013-12-08 09:21	That patch doesn't look right to me either.

(0034749) Julian Ospald (reporter) 2013-12-08 12:39	Then explain what does not look right. I cannot help with such vague statements.

(0034750) 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.

(0034751) Julian Ospald (reporter) 2013-12-08 13:21	you have probably missed our ignored bug report here http://www.cmake.org/Bug/view.php?id=13959 [^]

(0034752) 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.

(0034753) 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.

(0034754) 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-2.8.11.2-FindFreetype.patch fixes that, thanks to Rafał Mużyło

(0034757) 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.

(0034758) 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.

(0042435) 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.