[cmake-developers] Targets for FindGTK2.cmake

[Stephen Kelly]

Daniele E. Domenichelli wrote:

> Hello Stephen,
> 
> Sorry for the delay, but I was on holiday...
> 
> 
> On 14/08/13 15:07, Stephen Kelly wrote:
>> Daniele E. Domenichelli wrote:
>>> I did a few more tests, and it looks like that, at least on my system
>>> and on windows, FREETYPE_LIBRARIES are not required, they are linked to
>>> some other libraries (i.e. cairo) but they don't need to be linked
>>> explicitly
>>> On the other hand, the FREETYPE_INCLUDE_DIR is required, because some
>>> public header includes freetype headers.
>> 
>> Can you confirm that the things used in those cases from the headers are
>> only defines, enum values, inline functions etc, and not anything that
>> becomes part of the ABI (such as inheriting from a type etc)? Or,
>> otherwise, can you determine why the freetype header is in the public
>> headers?
> 
> I think I can confirm it... at least on the versions I have on my system
> (debian testing) and on windows (gtkmm installer), the only file
> included in GTK2 (& related libraries) include files seems to be
> ft2build.h that includes freetype/config/ftheader.h that contains only
> macros + one more include, but only when freetype is built. Therefore
> I'm quite sure that it is not necessary to link libfreetype explicitly.

Ok, great. Thanks for checking that.

> 
> This is another build machine on the dashboard (SunOS5.9-CC) where
> FindFreetype causes issues.
> 
> http://open.cdash.org/testDetails.php?test=206968805&build=3019758
> 
> I'm quite sure now that just not linking FREETYPE_LIBRARY explicitly is
> the way to fix this on all the systems... Am I allowed to make a commit
> and eventually revert it in order to test on the build machines if it
> works on all systems?

Yes, sometimes there is no other way to get that kind of feedback about 
problems reported by the dashboard. Another option of debugging dashboard 
problems is asking the operator of the machine to test something. 

Generally I think making commits in order to test behavior on a particular 
machine is ok if it doesn't cause general disruption on all dashboards 
(though I've been guilty of doing that before :) ). Then again, they're not 
my machines/hardware :).

>>> On window using gtkmm installer, find_package(Freetype) freetype is not
>>> found, FREETYPE_FOUND is FALSE, FREETYPE_LIBRARY is
>>> FREETYPE_LIBRARY-NOTFOUND, but FREETYPE_INCLUDE_DIR is set correctly
>>> (the headers are installed, but the .lib file is missing)
>>> I'm not sure if this is a bug in FindFreetype (FREETYPE_INCLUDE_DIR
>>> should be unset if freetype was not found?)
>> 
>> Perhaps. If so, maybe that's something FPHSA should do? Seems like a
>> separate topic though.
>> 
>> Do you mean that the windows gtk installer does not install the .lib file
>> at all, but does install the include files (because it only uses
>> defines/enums and doesn't need to link to the thing?)?
> 
> It installs the headers and the .dll, but not the .lib. Therefore
> libraries and executables already linked with, will find the required
> .dll when they are executed, but it is impossible to link new ones.

Ok.

> The includes used by GTK2 only have defines but the other freetype
> include files define methods, etc. though, so if one of those is
> included directly, the build will fail to find the symbols.

I think this is ok. Downstreams will have to link to freetype directly if 
they want to use it directly, and nothing newly-breaks as that has always 
been the case.

> Therefore I believe that I should just look for the 2 include files
> required by GTK2 only. FindFreetype already defines
> FREETYPE_INCLUDE_DIR_ft2build and FREETYPE_INCLUDE_DIR_freetype2 that
> look exactly for these files, and FREETYPE_INCLUDE_DIRS is defined as
> 
> set(FREETYPE_INCLUDE_DIRS
> "${FREETYPE_INCLUDE_DIR_ft2build};${FREETYPE_INCLUDE_DIR_freetype2}")
> 
> but I wonder if it is correct to leave this variable set, even if
> FREETYPE_FOUND is FALSE.

Something to put to a wider audience in a separate thread I think. I can see 
how such behavior could be considered backward incompatible (though the 
_FOUND variable should technically be checked).

> Anyway I believe that instead of checking for FREETYPE_FOUND, I could
> check and use FREETYPE_INCLUDE_DIR_ft2build and
> FREETYPE_INCLUDE_DIR_freetype2 directly, and that FREETYPE_INCLUDE_DIRS
> should be unset if FREETYPE_FOUND is false

Seems fine to me.

> 
> 
>> Btw, was there any effort to get the gtk upstream to produce cmake config
>> files with IMPORTED targets?
> 
> Not that I know about, and almost for sure not for GTK2 since afaik the
> development is now focused on GTK3
> 

Ok. Thanks for your thorough research on this!

Steve.