Re: [cmake-developers] Targets for FindGTK2.cmake
Hello Brad, On 25/09/13 17:01, Brad King wrote: I noticed that on some builds, all the tests for GTK2Targets suddenly disappeared: londinium.kitware: http://open.cdash.org/viewTest.php?buildid=3039037 TheGibson.kitware: http://open.cdash.org/viewTest.php?buildid=3039001 Is it my fault or if they were explicitly disabled? Didn't you change the tests to be conditional on certain dependencies existing? According to the latest builds http://open.cdash.org/testDetails.php?test=211425751build=3046984 http://open.cdash.org/testDetails.php?test=211450654build=3047132 these even thought the target GTK2::gtk exists, but the GTK2Targets.gtk test is not executed (while the GTK2Components.gtk is executed). the only condition is if(TARGET GTK2::gtk) (see Tests/FindGTK2/CMakeLists.txt) but as you can see in the output of the GTK2Components.gtk that target exists... Therefore I don't see any reason why these tests should not be executed. Is it possible that for some reason these tests are disabled on these machines? Cheers, 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
Re: [cmake-developers] Targets for FindGTK2.cmake
On 10/03/2013 11:57 AM, Daniele E. Domenichelli wrote: According to the latest builds http://open.cdash.org/testDetails.php?test=211425751build=3046984 http://open.cdash.org/testDetails.php?test=211450654build=3047132 these even thought the target GTK2::gtk exists, but the GTK2Targets.gtk test is not executed (while the GTK2Components.gtk is executed). the only condition is if(TARGET GTK2::gtk) (see Tests/FindGTK2/CMakeLists.txt) but as you can see in the output of the GTK2Components.gtk that target exists... Therefore I don't see any reason why these tests should not be executed. The problem is that the find_package(GTK2) in Tests/CMakeLists.txt and the target checks in Tests/FindGTK2/CMakeLists.txt are all being run by the existing CMake on the system that is used to build this CMake. The older version's FindGTK2 does not define any targets. Only on dashboard builds that bootstrap the tested version of CMake will the new FindGTK2 module be used. -Brad -- 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
Re: [cmake-developers] Targets for FindGTK2.cmake
On 10/02/2013 06:13 AM, Daniele E. Domenichelli wrote: I tried to add some debug output, because I cannot understand what's going on in the build machines, because the tests are still missing. Unfortunately I get messages like The rest of the test output was removed since it exceeds the threshold of 1024 bytes. Print the literal string CTEST_FULL_OUTPUT somewhere in the test output and it won't be truncated. -Brad -- 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
Re: [cmake-developers] Targets for FindGTK2.cmake
Hello Brad, Sorry for the delay. On 12/09/13 10:57, Daniele E. Domenichelli wrote: On 11/09/13 19:21, Brad King wrote: Do these tests share a build tree? GTK2Targets.gtk and GTK2Components.gtk failed randomly last night: http://open.cdash.org/viewTest.php?onlyfailedbuildid=3025432 Looks like that all the tests are fixed on all the builds now :) http://open.cdash.org/testSummary.php?project=1name=GTK2Targets.gtkdate=2013-09-19 http://open.cdash.org/testSummary.php?project=1name=GTK2Components.gtkdate=2013-09-19 Cheers, 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
Re: [cmake-developers] Targets for FindGTK2.cmake
On 11/09/13 19:21, Brad King wrote: Do these tests share a build tree? GTK2Targets.gtk and GTK2Components.gtk failed randomly last night: http://open.cdash.org/viewTest.php?onlyfailedbuildid=3025432 Both start with the output: Internal cmake changing into directory: /home/kitware/Dashboards/My Tests/CMakeGNU-build/Tests/FindGTK2/gtk The tests run in parallel so they must use different directories. Actually they do... I put them in the same directory because they just compile the same files in different ways, I didn't know this could cause issues. I will fix them. Also I noticed that the tests are failing on some other systems, I'll try to fix them as well... Thanks. 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
Re: [cmake-developers] Targets for FindGTK2.cmake
On 08/06/2013 05:39 AM, Daniele E. Domenichelli wrote: I added a commit introducing a couple of unit tests that should run only if GTK and/or GTKMM are available on the system. Do these tests share a build tree? GTK2Targets.gtk and GTK2Components.gtk failed randomly last night: http://open.cdash.org/viewTest.php?onlyfailedbuildid=3025432 Both start with the output: Internal cmake changing into directory: /home/kitware/Dashboards/My Tests/CMakeGNU-build/Tests/FindGTK2/gtk The tests run in parallel so they must use different directories. Thanks, -Brad -- 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
Re: [cmake-developers] Targets for FindGTK2.cmake
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.
This is another build machine on the dashboard (SunOS5.9-CC) where
FindFreetype causes issues.
http://open.cdash.org/testDetails.php?test=206968805build=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?
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.
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.
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.
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
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
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
Re: [cmake-developers] Targets for FindGTK2.cmake
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=206968805build=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.
--
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
Re: [cmake-developers] Targets for FindGTK2.cmake
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
Re: [cmake-developers] Targets for FindGTK2.cmake
Daniele E. Domenichelli wrote:
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?
My personal view is that you should recommend people to use the target names
directly and not the variables :), but I know that view is not universally
shared.
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.
Brad can squash up your branch before merging to master if he wants to.
* 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.
I think that's your call as the maintainer or Brads call.
* 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.
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?
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?)?
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)
It seems so, yes.
Btw, was there any effort to get the gtk upstream to produce cmake config
files with IMPORTED targets?
Thanks,
Steve.
--
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
Re: [cmake-developers] Targets for FindGTK2.cmake
Hello Stephen,
Thanks for the review
On 09/08/13 10:50, Stephen Kelly wrote:
* What is GTK2_GDKCONFIG_INCLUDE_DIR compared to GTK2_GDK_INCLUDE_DIR? Can
you conditionally append GTK2_GDKCONFIG_INCLUDE_DIR if it is not STREQUAL
GTK2_GDK_INCLUDE_DIR?
GTK2 has config files that usually are not in the same directory as
the other include files. Therefore there are 2 different variables, and
both needs to be included (for example gdk/gdk.h includes
gdk/gdktypes.h that includes gdkconfig.h)
I will add a check to ensure that the same path is not added twice (even
though I didn't see any system where they are the same)
* Populating the INTERFACE_COMPILE_DEFINITIONS can be wrapped in
if(GTK2_DEFINITIONS) as it is only set when using msvc with two of the
targets. No need to set it to an empty string in all other cases.
Ok
* set(GTK2_${_var}_LIBRARY GTK2::${_basename} PARENT_SCOPE) seems to
override the user variable for the library and makes it impossible for the
user to set the library location by overriding the cache, right?
This is something I took from FindQT4.cmake...
The GTK2_${_var}_LIBRARY are not cached, it is generated from
GTK2_${_var}_LIBRARY_DEBUG and GTK2_${_var}_LIBRARY_RELEASE (that are
cached). The user can override these 2 variables, and they will end in
the target and in the GTK2_${_var}_LIBRARY variable
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.
I think it can be useful during a transition from variables to targets...
Does it sound wrong?
* 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...
To be honest want to be able to backport the module, even though not the
target part (INTERFACE_INCLUDE_DIRECTORIES won't work anyway afaik), so
I can remove the
* The diff contains this:
+#_GTK2_ADD_TARGET_DEPENDS(GOBJECT glib)
+_GTK2_ADD_TARGET_DEPENDS(GOBJECT glib)
It should be already removed in one of the following commits, I'm not
sure if it is possible to squash commits/rebase topics published and
merged to next.
* 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.
Does this add the glib target twice?
* 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.
On the other hand, pkg-config --libs gtk+-2.0 on my system reports
that the freetype library is required, even though the headers does not
seem to ... (I'm still investigating this).
Also for fontconfig it looks like that it doesn't need to be linked,
even though pkg-config reports so...
By the way, fontconfig is a freedesktop package, it is not part of GTK,
does it sound reasonable to create a module for that (possibly with
imported targets)
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
Re: [cmake-developers] Targets for FindGTK2.cmake
Daniele E. Domenichelli wrote:
Hello Stephen,
Thanks for the review
On 09/08/13 10:50, Stephen Kelly wrote:
* What is GTK2_GDKCONFIG_INCLUDE_DIR compared to GTK2_GDK_INCLUDE_DIR?
Can you conditionally append GTK2_GDKCONFIG_INCLUDE_DIR if it is not
STREQUAL GTK2_GDK_INCLUDE_DIR?
GTK2 has config files that usually are not in the same directory as
the other include files. Therefore there are 2 different variables, and
both needs to be included (for example gdk/gdk.h includes
gdk/gdktypes.h that includes gdkconfig.h)
I will add a check to ensure that the same path is not added twice (even
though I didn't see any system where they are the same)
Ok, probably no need for the additional STREQUAL check then.
* set(GTK2_${_var}_LIBRARY GTK2::${_basename} PARENT_SCOPE) seems to
override the user variable for the library and makes it impossible for
the user to set the library location by overriding the cache, right?
This is something I took from FindQT4.cmake...
The GTK2_${_var}_LIBRARY are not cached, it is generated from
GTK2_${_var}_LIBRARY_DEBUG and GTK2_${_var}_LIBRARY_RELEASE (that are
cached). The user can override these 2 variables, and they will end in
the target and in the GTK2_${_var}_LIBRARY variable
Ok, thanks for the explanation. I'm sure that's fine then.
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...
I think it can be useful during a transition from variables to targets...
Does it sound wrong?
It's probably ok.
* 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.
To be honest want to be able to backport the module, even though not the
target part (INTERFACE_INCLUDE_DIRECTORIES won't work anyway afaik), so
I can remove the
Something missing here, but if backporting is the motivation, I can see the
reasoning. No need to remove the
IMPORTED_LINK_INTERFACE_LIBRARIES_${_config} if you don't want to.
* The diff contains this:
+#_GTK2_ADD_TARGET_DEPENDS(GOBJECT glib)
+_GTK2_ADD_TARGET_DEPENDS(GOBJECT glib)
It should be already removed in one of the following commits,
Indeed. I looked again at git diff stage/master...stage/FindGTK2-targets and
didn't find that chunk. Odd. I thought that's what I did before too...
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.
* 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.
Does this add the glib target twice?
I'm not sure. Even if it does, that shouldn't be harmful.
* 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.
On the other hand, pkg-config --libs gtk+-2.0 on my system reports
that the freetype library is required, even though the headers does not
seem to ... (I'm still investigating this).
Also for fontconfig it looks like that it doesn't need to be linked,
even though pkg-config reports so...
Ok.
By the way, fontconfig is a freedesktop package, it is not part of GTK,
does it sound reasonable to create a
Re: [cmake-developers] Targets for FindGTK2.cmake
Brad King wrote:
On 08/06/2013 05:39 AM, Daniele E. Domenichelli wrote:
I added a commit introducing a couple of unit tests that should run only
if GTK and/or GTKMM are available on the system.
Thanks. Steve, please take a quick look at this topic to
review how the imported targets are constructed.
Here's my remarks:
* Using double-semicolons. Good.
* Release and debug libraries handled. Good.
* Release listed before Debug. Good. RelWithDebInfo etc should work.
* What is GTK2_GDKCONFIG_INCLUDE_DIR compared to GTK2_GDK_INCLUDE_DIR? Can
you conditionally append GTK2_GDKCONFIG_INCLUDE_DIR if it is not STREQUAL
GTK2_GDK_INCLUDE_DIR?
* Populating the INTERFACE_COMPILE_DEFINITIONS can be wrapped in
if(GTK2_DEFINITIONS) as it is only set when using msvc with two of the
targets. No need to set it to an empty string in all other cases.
* set(GTK2_${_var}_LIBRARY GTK2::${_basename} PARENT_SCOPE) seems to
override the user variable for the library and makes it impossible for the
user to set the library location by overriding the cache, right?
This line should not be needed anyway. I guess you want
if (GTK2_USE_IMPORTED_TARGETS)
list(APPEND GTK2_LIBRARIES GTK2::${basename})
else()
list(APPEND GTK2_LIBRARIES ${GTK2_${_var}_LIBRARY})
endif()
instead.
However, even then I don't recommend it. I'd say document that users should
use the imported target names directly if they want. Alex disagrees of
course, and would want you to populate a LIBRARY_TARGETS variable (I don't
see the point). I guess this change is not 2.8.12 material anyway though, so
maybe we'll finally sort all that out for in the next release anyway.
* 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.
* The diff contains this:
+#_GTK2_ADD_TARGET_DEPENDS(GOBJECT glib)
+_GTK2_ADD_TARGET_DEPENDS(GOBJECT glib)
* 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.
* 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)?
* Thanks for the initiative. I have patches for zlib and png adding imported
targets, but I'm waiting for
http://public.kitware.com/Bug/view.php?id=14082. I'd like to add imported
targets to most Find modules shipped with cmake eventually.
Thanks,
Steve.
--
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
Re: [cmake-developers] Targets for FindGTK2.cmake
On 08/06/2013 05:39 AM, Daniele E. Domenichelli wrote: I added a commit introducing a couple of unit tests that should run only if GTK and/or GTKMM are available on the system. Thanks. Steve, please take a quick look at this topic to review how the imported targets are constructed. Thanks, -Brad -- 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
Re: [cmake-developers] Targets for FindGTK2.cmake
Hello Philip, Thanks for your comments. On 06/08/13 05:43, Philip Lowman wrote: I'm not sure if there is a way to develop automated unit tests and mark them to not run by default. That would be useful for regression testing of modules even if it the tests had to be run manually. I added a commit introducing a couple of unit tests that should run only if GTK and/or GTKMM are available on the system. 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
Re: [cmake-developers] Targets for FindGTK2.cmake
Daniele,
Your changes look fine to me although my experience with imported targets
is limited so someone with more experience should review your changes there.
I'm not sure if there is a way to develop automated unit tests and mark
them to not run by default. That would be useful for regression testing of
modules even if it the tests had to be run manually. Would be a good
question for some of the more active developers (read: not me) :).
If compilation of the hello world examples is still working for you, that
would be a pretty good sign you didn't break anything.
https://developer.gnome.org/gtk-tutorial/stable/c39.html#SEC-HELLOWORLD
https://developer.gnome.org/gtkmm-tutorial/2.24/sec-helloworld.html.en
Here's some old test code I had lying around which obviously could be much
improved.
*CMakeLists.txt*
project(foo)
cmake_minimum_required(VERSION 2.6)
set(GTK2_DEBUG TRUE)
set(CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR})
find_package(GTK2 2.16 REQUIRED gtk glade gtkmm glademm)
message(GTK2_INCLUDE_DIRS = ${GTK2_INCLUDE_DIRS})
message(GTK2_LIBRARIES = ${GTK2_LIBRARIES})
include_directories(${GTK2_INCLUDE_DIRS})
add_executable(bar bar.cc helloworld.cc)
target_link_libraries(bar ${GTK2_LIBRARIES}
*bar.cc:*
#include gtkmm/main.h
#include helloworld.h
int main (int argc, char *argv[])
{
Gtk::Main kit(argc, argv);
HelloWorld helloworld;
//Shows the window and returns when it is closed.
Gtk::Main::run(helloworld);
return 0;
}
*helloworld.cc*
#include helloworld.h
#include iostream
HelloWorld::HelloWorld()
: m_button(Hello World) // creates a new button with label Hello
World.
{
// Sets the border width of the window.
set_border_width(10);
// When the button receives the clicked signal, it will call the
// on_button_clicked() method defined below.
m_button.signal_clicked().connect(sigc::mem_fun(*this,
HelloWorld::on_button_clicked));
// This packs the button into the Window (a container).
add(m_button);
// The final step is to display this newly created widget...
m_button.show();
}
HelloWorld::~HelloWorld()
{
}
void HelloWorld::on_button_clicked()
{
std::cout Hello World std::endl;
}
*helloworld.h*
#ifndef GTKMM_EXAMPLE_HELLOWORLD_H
#define GTKMM_EXAMPLE_HELLOWORLD_H
#include gtkmm/button.h
#include gtkmm/window.h
class HelloWorld : public Gtk::Window
{
public:
HelloWorld();
virtual ~HelloWorld();
protected:
//Signal handlers:
void on_button_clicked();
//Member widgets:
Gtk::Button m_button;
};
#endif // GTKMM_EXAMPLE_HELLOWORLD_H
On Mon, Aug 5, 2013 at 11:00 AM, Daniele E. Domenichelli
daniele.domeniche...@gmail.com wrote:
Hello all,
I'd like to introduce imported targets in FindGTK2.cmake, in a similar
manner as they are used in FindQT4.cmake.
The aim is to be able to do something like:
find_package(GTK2 gtk gtkmm)
target_link_libraries(target GTK2::gtkmm)
(In the future I want to handle dependencies on modules as well, at the
moment I think that if you don't include the gtk module it will not work)
If you want to review my changes, you can checkout the FindGTK2-targets
topic. I tested it on Windows and Linux, but unfortunately there are not
unit tests afaik.
Cheers,
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
--
Philip Lowman
--
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
