On 12/08/13 15:36, Stephen Kelly wrote:
>> The difference is that if GTK2_USE_IMPORTED_TARGETS the
>> GTK_${_var}_LIBRARY will link the target (and it's dependencies)
>> otherwise it will link only the library (without dependencies) using the
>> DEBUG or RELEASE version, depending on what was found.
> 
> Are there also GTK_${_var}_LIBRARIES variables? 
> 
> Conventionally, the *LIBRARIES variables are for user-use and the *LIBRARY 
> variables are not...

Not at the moment, but perhaps it might be useful to add them... What do
you think?


>>> * CMake 2.8.12 will ignore IMPORTED_LINK_INTERFACE_LIBRARIES_${_config},
>>> so you don't need to set it. The only reason to want to set it is if you
>>> want people to backport this updated module. I don't recommend setting
>>> it.
>>
>> Does this mean that setting the INTERFACE_LINK_LIBRARIES is enough?
>> Again I took this from FindQT4...
> 
> Yes, I didn't remove it from there yet. I do intend to though probably after 
> CMake 2.8.12.
[...]
> No need to remove the 
> IMPORTED_LINK_INTERFACE_LIBRARIES_${_config} if you don't want to.

Then, I think I'll leave it there for now...


>> I'm not
>> sure if it is possible to squash commits/rebase topics published and
>> merged to next.
> 
> It's possible, but a bit tricky. If you rebase, the result of the rebasing 
> needs to be the exact same as what is already in next. When fixing up a 
> branch, that means making fixup commits, then pushing them, then squashing 
> the fixes with a rebase, then force pushing. You can test the merge to 
> stage/next locally too.

I tried locally but I get merge conflicts, so I'm not sure if I'm doing
it right... If it is not an issue, I'd just leave the extra commit.


>>> * If GObject depends on glib, then the line
>>> _GTK2_ADD_TARGET_DEPENDS(ATK gobject glib) does not need to specify glib.
>>> I would minimise those dependency listings.
>>
>> atk explicitly requires glib (glib.h is included in some headers)
>> therefore I thought it was better to make this explicit here as well.
> 
> *shrug*. I've seen the same argument presented before, but I don't agree 
> with it. As you wish.

I'm not expert, I'm just saying what I thought when I wrote it, so if
you think it is better in the other way I can change it.


>>> * fontconfig seems to be only a compile dependency but not a link
>>> dependency.
>>>
>>> * freetype seems to be a link dependency (I assume, as it is added to
>>> GTK2_LIBRARIES), but the library does not seem to be in the link
>>> interface of the Cairo library. ${FREETYPE_LIBRARIES} can just be added
>>> to the INTERFACE_LINK_LIBRARIES, but I think it might make sense to
>>> create an imported target for it too anyway (in FindFreetype.cmake)?
>>
>> To be honest I'm not completely sure here... On windows (with the GtkMM
>> installer) I'm having some issues with freetype, when linking
>> ${GTK2_LIBRARIES}, but it links when I use the libraries one by one.
> 
> It would be interesting to get more information on this.

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.

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?)
On the other hand, fixing this means that building gtk programs will
fail. Perhaps FindGTK2 should NOT use FindFreetype and should look for
the headers only internally (like for fontconfig)


Regards,
 Daniele
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Reply via email to