from:"Philipp Moeller"

Re: [cmake-developers] IMPORTED targets for some Find modules

2014-06-25 Thread Philipp Moeller

Stephen Kelly steve...@gmail.com writes:

 Philipp Möller wrote:

 To simplify exporting targets I added IMPORTED targets to some of the
 Find modules.

 Thanks for working on this. Just a few minor comments:

 In the FindX11 documentation commit, one of the changes is to replace use of 
 two spaces between sentences with one. That's counter to the prevailing 
 style in CMake.

 cmExportFileGenerator marks frameworks with a FRAMEWORK target property, and 
 Qt 5 emulates that. It could be done with these files too (I notice in 
 FindGLUT at least). I don't know if it has any effect on IMPORTED targets, 
 but it may in the future even if it does not currently.

That sounds like a good idea. Although I think that would make things
very confusing: the IMPORTED_LOCATION would be the full path of the
library, the INTERFACE_INCLUDE_DIRECTORIES would be the full path to the
includes, but all of this is ignored as soon as -framework is used and
the full path to the framework isn't specified (as far as my
understanding of OSX goes).

Maybe it would make sense to add a FRAMEWORK library type and a
find_framework command to encapsulate all this. It would make writing
those imports a lot smoother as well.

 Is there any reason to make the boost components not depend on each other? 
 Or is that just left for future development?

 The Boost module documents that component imported targets have lower-case 
 names, but that is not the case (haha). The names depend on the arguments to 
 find_package currently:

  find_package(Boost REQUIRED Thread)

  if (TARGET Boost::Thread)
message(YES)
  else()
message(NO)
  endif()

AFAIK, the documentation says that components should be specified by
their canonical name. Unfortunately, it doesn't say what that is
exactly and I blindly assumed it to always be lower-case. I'll fix
this.

 It looks like a good idea to add Boost::boost to the 
 INTERFACE_LINK_LIBRARIES of each component imported target, or to similarly 
 populate the INTERFACE_INCLUDE_DIRECTORIES of each component imported 
 target.

I contemplated that, but here I tried to anticipate Boost
modularization. If we ever get specific include directories for each
component we can break a lot of builds that wrongly relied on the fact
that we brought in all of the Boost includes. If the includes are
separated, this will be much easier to adapt to for users.

 I would say something similar about the GLUT imported targets, but it seems 
 that only GLUT::GLUT is documented, so presumably it is the only one 
 intended for users to use. Is it verified that the other libraries are 
 really interface dependencies and not runtime requirements? If they are 
 really interface usage requirements, where are the headers of the other 
 libraries located?

I don't understand what you mean by 'runtime requirements'. GLUT
depends on either some X11 libraries or Cocoa for window creation, but
doesn't expose the system APIs directly. You will still need to link
against them.

I just went through the freeglut implementation and the external
headers are only windows.h, gl.h, and glu.h. Those dependencies also
missing in the original FindGLUT and this would be a worthwhile fix.

 Multiple IMPORTED_LOCATION_CONFIG are populated on the boost targets, but 
 the IMPORTED_CONFIGURATIONS target property is not populated.

Thanks. Didn't know this was necessary. Will be fixed.

 Is there a need to populate the IMPORTED_IMPLIB_CONFIG target properties 
 on Windows for any of the targets?

I don't have a Windows machine available right now, but I can try to
figure this out later. Windows users tend to rely on Boost
auto-linking though, which unfortunately doesn't interact very well with
IMPORTED targets.

 cmExportFileGenerator populates the IMPORTED_LINK_INTERFACE_LANGUAGES target 
 property, and Qt 5 emulates that. The same could be set to CXX at least for 
 the Boost targets.

Will be fixed.

 One of the reasons Qt imported targets are called Qt4::Foo and Qt5::Foo is 
 to avoid accidental combination of, say, Qt::Core and Qt::Gui from different 
 major versions. They also encode a INTERFACE_QT_MAJOR_VERSION and add  
 QT_MAJOR_VERSION to the COMPATIBLE_INTERFACE_STRING target property. 
 Something similar could be added for these imported targets.

 In the case of Boost, because they don't provide binary compatibility or 
 promise source compatibility, it might make sense to encode the full 
 version, not only the major version, in a similar way to ensure that only 
 boost libraries from the same boost release are used together. In the 
 future, post modularization, boost may attempt to release some modules on a 
 separate release schedule and with disparate version numbers. They may still 
 release 'boost foobar 1.3' with 'Boost 1.58' though, so '1.58' would still 
 be the appropriate 'distribution version' to encode. 

[...snipped...]


 In the case of boost, it would also make sense to add 
 INTERFACE_MULTITHREADED to the targets and

Re: [cmake-developers] IMPORTED targets for some Find modules

2014-06-25 Thread Philipp Moeller

Nils Gladitz nilsglad...@gmail.com
writes:

 On 06/25/2014 02:53 PM, Stephen Kelly wrote:
 David Cole via cmake-developers wrote:

 Thanks. That indeed doesn't seem to interact well with CMake.

 The introduction of imported targets is an opportunity to add the necessary
 define to disable it to INTERFACE_COMPILE_DEFINITIONS by default, if that is
 desired.

 I would like that very much as well.

I'll look into doing that. I think populating
INTERFACE_COMPILE_DEFINTIONS with BOOST_${LIBRARY_NAME}_NO_LIB seems the
obvious choice. In addition I can provide a Boost::disable_autolinking
target to disable it for the complete library.

 I've got a custom FindBoost.cmake which basically just wraps the
 actual FindBoost module and sets the BOOST_ALL_NO_LIB definition.

Another option is to wrap FindBoost and simply unset ${Boost_LIBRARIES}
on Windows after it completed and to make sure the link directories are
set.

 This seems to be a source of confusion for people who are unaware of
 autolinking in general.

 Having CMake find and link one set of libraries (DLL by default) and
 the lib pragmas link yet another set of libraries (static by default).


-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [cmake-developers] IMPORTED targets for some Find modules

2014-06-25 Thread Philipp Moeller

Stephen Kelly steve...@gmail.com writes:

 Philipp Moeller wrote:

[...snipped...]

 I contemplated that, but here I tried to anticipate Boost
 modularization. If we ever get specific include directories for each
 component we can break a lot of builds that wrongly relied on the fact
 that we brought in all of the Boost includes. If the includes are
 separated, this will be much easier to adapt to for users.

 If you populate the INTERFACE_INCLUDE_DIRECTORIES on each component IMPORTED 
 target, what can go wrong?

On a non-modularized build I will need to populate it with
Boost_INCLUDE_DIR as we don't do detection of different include
directories yet. This would allow users to accidentally use headers from
a different component. The way it is done now, users will be aware that
they bring in all includes and know what to change if they wish to use a
modular Boost.

 I would say something similar about the GLUT imported targets, but it
 seems that only GLUT::GLUT is documented, so presumably it is the only
 one intended for users to use. Is it verified that the other libraries
 are really interface dependencies and not runtime requirements? If they
 are really interface usage requirements, where are the headers of the
 other libraries located?
 
 I don't understand what you mean by 'runtime requirements'. GLUT
 depends on either some X11 libraries or Cocoa for window creation, but
 doesn't expose the system APIs directly. You will still need to link
 against them.

 You mean they must appear on the link line of your program? If so, then they 
 are public dependencies of GLUT.

 Or they have to be available only at runtime? If so then they are private 
 dependencies of GLUT.

 If they must appear on the link line of your program, then your program must 
 use symbols from it, and then you need to have a definition of those symbols 
 at compile time, which is usually provided in header files.

Not necessarily. Imagine:

foo.h:

void f();

foo.cpp:
#include foo.h
#include GL/gl.h

void f() { 
  glVertex2i(1, 2);
}

If you build a library using foo.cpp it will contain the glVertex2i
symbol even though its headers wont include it. Likewise a consumer of
that library does not need to have the headers, but will need to link
against a library containing the symbol. This is exactly the case in
GLUT. Thus they need to be PUBLIC or INTERFACE dependencies.

 Typically that happens if the headers of one library (Cocoa, in this case I 
 think) are #included in the headers of another library (GLUT, in this case I 
 think).

 Is that the case? If not, then Cocoa is a private dependency.

 
 I just went through the freeglut implementation and the external
 headers are only windows.h, gl.h, and glu.h. Those dependencies also
 missing in the original FindGLUT and this would be a worthwhile fix.

 Then Cocoa etc are 'private dependencies', not 'public dependencies' and do 
 not need to appear in the INTERFACE_LINK_LIBRARIES target property.

[...snipped...]


-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [cmake-developers] IMPORTED targets for some Find modules

2014-06-25 Thread Philipp Moeller

Stephen Kelly steve...@gmail.com writes:

 Philipp Moeller wrote:

 Nils Gladitz nilsglad...@gmail.com
 writes:
 I would like that very much as well.
 
 I'll look into doing that. I think populating
 INTERFACE_COMPILE_DEFINTIONS with BOOST_${LIBRARY_NAME}_NO_LIB seems the
 obvious choice. 

 Yes.

 In addition I can provide a Boost::disable_autolinking
 target to disable it for the complete library.

 Also consider a CMake variable to disable the addition of the defines (by 
 not linking the interface targets).

  set(Boost_ENABLE_AUTOLINKING 1)
  find_package(Boost)

I really would like to do that, but for that to work we need a
LINK_DIRECTORIES property. I opened a feature request for this some time
ago.

Let me give a quick summary of how auto-linking works so we have a
common understanding of it:

A header uses pragma comment(lib, library_name.lib). This triggers the
compiler to look for library_name.lib in all specified and implicit link
directories.

I think this sums up what we need: If we enable auto-linking the
IMPORTED targets need to be INTERFACE targets that propagate a
INTERFACE_LINK_DIRECTORY property if the compiler supports
auto-linking. If it is disabled or the compiler does not support it, we
need a UNKNOWN or STATIC library target with an
INTERFACE_COMPILE_DEFINITIONS to disable auto-linking.

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [cmake-developers] IMPORTED targets for some Find modules

2014-06-25 Thread Philipp Moeller

Stephen Kelly steve...@gmail.com writes:

 Philipp Moeller wrote:

 Stephen Kelly steve...@gmail.com writes:

 If you populate the INTERFACE_INCLUDE_DIRECTORIES on each component
 IMPORTED target, what can go wrong?
 
 On a non-modularized build I will need to populate it with
 Boost_INCLUDE_DIR as we don't do detection of different include
 directories yet. This would allow users to accidentally use headers from
 a different component.

 Please correct me where I go wrong here:

 1) All boost releases (including the next one) are monolithic
 2) So there is only one Boost_INCLUDE_DIR
 3) So, different components don't have different usage-include-directories

 Are you talking about a scenario where there are multiple different Boost 
 installations found at different prefixes? 

 Or what do you mean about 'accidentally using headers from a different 
 component'?

 The way it is done now, users will be aware that
 they bring in all includes and know what to change if they wish to use a
 modular Boost.

  add_executable(foo main.cpp)
  target_link_libraries(foo Boost::thread)

 should 'just work' without having to add another target to provide the 
 include dir.

 I don't understand what you're saying or arguing for here, but if Brad does 
 I guess he'll merge it :).

I was talking about a modularized Boost which doesn't use CMake. As
long as stuff is monolithic this will bring in all include directories
and the build will be harder to modularize. The way it is done now a
user would need:

add_executable(foo main.cpp)
target_link_libraries(foo Boost::boost Boost::thread)

and be aware that this just brought in all includes. If she ever
switches to a modularized Boost this becomes:

add_executable(foo main.cpp)
target_link_libraries(foo Boost::thread)

Maybe my thinking is too complex here and your example has merit. Some
stuff should just work.

 If you build a library using foo.cpp it will contain the glVertex2i
 symbol even though its headers wont include it. Likewise a consumer of
 that library does not need to have the headers, 

 but will need to link against a library containing the symbol. 

 Ah, I guess we're talking about static libraries here.

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [cmake-developers] [PATCH 5/5] FindBoost.cmake: Add Boost::boost and Boost::C targets and documentation

2014-06-24 Thread Philipp Moeller

Stephen Kelly steve...@gmail.com writes:

 Brad King wrote:

 On 06/20/2014 01:09 PM, Philipp Möller wrote:
 +#   Boost::boost  - interface target containing the
 include
 +#   directory
 
 Nice.


 Note that Boost upstream is modularizing and may provide CMake config files 
 in the future:

  https://github.com/boost-cmake/boost-cmake
  https://svn.boost.org/trac/boost/wiki/CMakeModularizationStatus

 The wiki page is out of date, and so is the repo, because boost is trying to 
 make a release before finishing the modularization work and it is all on-
 hold for several more months.

This project has been going on for ages and considering how long it took
Boost to change their SCM or the (stalled?) ryppl and 0install efforts I
don't see this happening anytime soon. I'm of course not belittling any
of those efforts or the people behind them. Huge organizations are hard
to move and those that try deserve respect. It would certainly make my
life easier if they succeeded.

Exporting targets with proper dependencies is a problem now and lots of
projects depend on Boost. Improving the process now and even supporting
older versions of Boost is, IMO, worthwhile.

 This means:

  1) Creating a Boost::boost monolithic target may not be appropriate

IMO, even a modularized boost build should provide a target that just
gives you all of the includes for convenience in addition to more
fine-grained access, but I see why one would think otherwise.

 
  2) If FindBoost creates imported targets named Boost::*, then config
 files provided by boost upstream probably can't use that namespace
 (currently it uses boost::, but you might consider whether imported
 targets provided by files shipped with cmake should use CMake::).

Yes, I was thinking about that. So far I have only applied those changes
for packages which are highly unlikely to ever provide package configs
and so giving them their own namespace made sense to me. Their is also a
problem that some find-modules don't use other find-modules even where
they should (e.g. FindGLUT which is using Xmu and Xi, which could be
provided by FindX11). This could lead to inconsistencies between
targets, thus the encapsulation in the GLUT namespace.

Boost is a bit of a special case and changing the namespace to indicate
that one is using the CMake provided targets might be a good idea. What
about FindBoost::?

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [cmake-developers] [PATCH 5/5] FindBoost.cmake: Add Boost::boost and Boost::C targets and documentation

2014-06-24 Thread Philipp Moeller

Brad King brad.k...@kitware.com writes:

 On 06/20/2014 01:09 PM, Philipp Möller wrote:
 +#   Boost::boost  - interface target containing the include
 +#   directory

 Nice.

 +  if(Boost_USE_STATIC_LIBS)
 +add_library(Boost::${COMPONENT} STATIC IMPORTED)
 +  else()
 +add_library(Boost::${COMPONENT} SHARED IMPORTED)
 +  endif()

 IIRC, Boost_USE_STATIC_LIBS asks for static libraries, but when it is
 OFF we might still get static libraries.  Therefore the else() case
 still needs to mark it as UNKNOWN.

You are right. Attached is a fixed patch.

commit 240cfd47a4980965f18068f6f35c6b7071497d32
Author: Philipp Möller bootsare...@googlemail.com
Date:   Fri Jun 20 19:09:28 2014 +0200

FindBoost.cmake: Add Boost::boost and Boost::C targets and documentation

diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
index dfd4460..705b250 100644
--- a/Modules/FindBoost.cmake
+++ b/Modules/FindBoost.cmake
@@ -53,6 +53,24 @@
 #   Boost_C_LIBRARY_DEBUG   - Component C library debug variant
 #   Boost_C_LIBRARY_RELEASE - Component C library release variant
 #
+# In addition to the above variables this module creates the following
+# :prop_tgt:`IMPORTED` targets::
+#
+#   Boost::boost  - interface target containing the include
+#   directory
+#   Boost::C- shared or static library target for a
+#   component (C is lower-case)
+#   Boost::diagnostic_definitions - interface target to enable diagnostic
+#   information about Boost's automatic linking
+#   during compilation
+#
+# Component targets never depend on each even though they might
+# require each other. It is important to note that the imported
+# targets behave differently than variables created by this module:
+# multiple calls to find_package(Boost) in the same directory or
+# sub-directories with different options (e.g. static or shared) will
+# not override the values of the targets created by the first call.
+#
 # Users may set these hints or results as cache entries.  Projects
 # should not read these entries directly but instead use the above
 # result variables.  Note that some hint names start in upper-case
@@ -524,6 +542,13 @@ if(Boost_DEBUG)
  Boost_NO_SYSTEM_PATHS = ${Boost_NO_SYSTEM_PATHS})
 endif()
 
+# Supply Boost_LIB_DIAGNOSTIC_DEFINITIONS as a convenience target. It
+# will only contain any interface definitions on WIN32, but is created
+# on all platforms to keep end user code free from platform dependent
+# code.
+if(NOT TARGET Boost::diagnostic_definitions)
+  add_library(Boost::diagnostic_definitions INTERFACE IMPORTED)
+endif()
 if(WIN32)
   # In windows, automatic linking is performed, so you do not have
   # to specify the libraries.  If you are linking to a dynamic
@@ -543,6 +568,8 @@ if(WIN32)
   # code to emit a #pragma message each time a library is selected
   # for linking.
   set(Boost_LIB_DIAGNOSTIC_DEFINITIONS -DBOOST_LIB_DIAGNOSTIC)
+  set_target_properties(Boost::diagnostic_definitions PROPERTIES 
+INTERFACE_COMPILE_DEFINITIONS BOOST_LIB_DIAGNOSTIC)
 endif()
 
 _Boost_CHECK_SPELLING(Boost_ROOT)
@@ -1155,11 +1182,36 @@ else()
 endif()
 
 # 
-#  Notification to end user about what was found
+#  Notification to end user about what was found and creation of targets.
 # 
 
 set(Boost_LIBRARIES )
 if(Boost_FOUND)
+  if(NOT TARGET Boost::boost)
+add_library(Boost::boost INTERFACE IMPORTED)
+set_target_properties(Boost::boost PROPERTIES
+  INTERFACE_INCLUDE_DIRECTORIES ${Boost_INCLUDE_DIR})
+  endif()
+
+  foreach(COMPONENT ${Boost_FIND_COMPONENTS})
+string(TOUPPER ${COMPONENT} UPPERCOMPONENT)
+
+if(NOT TARGET Boost::${COMPONENT})
+  if(Boost_USE_STATIC_LIBS)
+add_library(Boost::${COMPONENT} STATIC IMPORTED)
+  else()
+# Even if Boost_USE_STATIC_LIBS is OFF, we might have static
+# libraries as a result.
+add_library(Boost::${COMPONENT} UNKNOWN IMPORTED)
+  endif()
+
+  set_target_properties(Boost::${COMPONENT} PROPERTIES
+IMPORTED_LOCATION ${Boost_${UPPERCOMPONENT}_LIBRARY_RELEASE}
+IMPORTED_LOCATION_RELEASE ${Boost_${UPPERCOMPONENT}_LIBRARY_RELEASE}
+IMPORTED_LOCATION_DEBUG ${Boost_${UPPERCOMPONENT}_LIBRARY_DEBUG})
+endif()
+  endforeach()
+
   if(NOT Boost_FIND_QUIETLY)
 message(STATUS Boost version: ${Boost_MAJOR_VERSION}.${Boost_MINOR_VERSION}.${Boost_SUBMINOR_VERSION})
 if(Boost_FIND_COMPONENTS)
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each

Re: [cmake-developers] [PATCH 4/5] FindGLUT.cmake: Add imported targets and documentation

2014-06-24 Thread Philipp Moeller

Brad King brad.k...@kitware.com writes:

 On 06/10/2014 05:55 AM, Philipp Möller wrote:
 The APPLE part works, but definitely could be improved upon.
 [snip]
 +if(APPLE)
 +  # Using the hardcoded paths is certainly not the best thing to
 +  # do, but it is done the include path already.
 +  set_target_properties(GLUT::GLUT PROPERTIES
 +IMPORTED_LOCATION /System/Library/Frameworks/GLUT.framework/GLUT)
 +  if(NOT TARGET GLUT::Cocoa)
 +add_library(GLUT::Cocoa UNKNOWN IMPORTED)
 +set_target_properties(GLUT::Cocoa PROPERTIES
 +  IMPORTED_LOCATION 
 /System/Library/Frameworks/Cocoa.framework/Cocoa)
 +  endif()
 +  set_target_properties(GLUT::GLUT PROPERTIES
 +INTERFACE_LINK_LIBRARIES GLUT::Cocoa)
 +else()

 The path to the framework is hard-coded for the include path only
 as a possible search location, not as a result.  The above code
 hard-codes it as a result.  FindGLUT is one of the only modules
 left that hard-codes -framework XYZ as a result on OS X instead
 of allowing find_library to locate the framework.  That needs to
 be fixed first, and then the framework path can be handled here
 the same way as it is in FindOpenGL.

I removed the -framework part and the code now checks if find_library
returned a path to a framework. I also removed the hard-coded path from
the find_library call so this now behaves like most other Find Modules. 

diff --git a/Modules/FindGLUT.cmake b/Modules/FindGLUT.cmake
index be7c0cd..9fe8aa0 100644
--- a/Modules/FindGLUT.cmake
+++ b/Modules/FindGLUT.cmake
@@ -2,7 +2,20 @@
 # FindGLUT
 # 
 #
-# try to find glut library and include files
+# try to find glut library and include files.
+#
+# IMPORTED Targets
+# 
+#
+# This module defines the :prop_tgt:`IMPORTED` targets:
+#
+# ``GLUT::GLUT``
+#  Defined if the system has GLUT.
+#
+# Result Variables
+# 
+#
+# This module sets the following variables:
 #
 # ::
 #
@@ -42,13 +55,21 @@ if (WIN32)
 else ()
 
   if (APPLE)
-# These values for Apple could probably do with improvement.
-find_path( GLUT_INCLUDE_DIR glut.h
-  /System/Library/Frameworks/GLUT.framework/Versions/A/Headers
-  ${OPENGL_LIBRARY_DIR}
-  )
-set(GLUT_glut_LIBRARY -framework GLUT CACHE STRING GLUT library for OSX)
-set(GLUT_cocoa_LIBRARY -framework Cocoa CACHE STRING Cocoa framework for OSX)
+find_path(GLUT_INCLUDE_DIR glut.h ${OPENGL_LIBRARY_DIR})
+find_library(GLUT_glut_LIBRARY GLUT DOC GLUT library for OSX)
+find_library(GLUT_cocoa_LIBRARY Cocoa DOC Cocoa framework for OSX)
+
+if(GLUT_cocoa_LIBRARY AND NOT TARGET GLUT::Cocoa)
+  add_library(GLUT::Cocoa UNKNOWN IMPORTED)
+  # Cocoa should always be a Framework, but we check to make sure.
+  if(GLUT_cocoa_LIBRARY MATCHES /([^/]+)\\.framework$)
+set_target_properties(GLUT::Cocoa PROPERTIES
+  IMPORTED_LOCATION ${GLUT_cocoa_LIBRARY}/${CMAKE_MATCH_1})
+  else()
+set_target_properties(GLUT::Cocoa PROPERTIES
+  IMPORTED_LOCATION ${GLUT_cocoa_LIBRARY})
+  endif()
+endif()
   else ()
 
 if (BEOS)
@@ -66,6 +87,18 @@ else ()
 /usr/openwin/lib
 )
 
+  if(GLUT_Xi_LIBRARY AND NOT TARGET GLUT::Xi)
+add_library(GLUT::Xi UNKNOWN IMPORTED)
+set_target_properties(GLUT::Xi PROPERTIES
+  IMPORTED_LOCATION ${GLUT_Xi_LIBRARY})
+  endif()
+
+  if(GLUT_Xmu_LIBRARY AND NOT TARGET GLUT::Xmu)
+add_library(GLUT::Xmu UNKNOWN IMPORTED)
+set_target_properties(GLUT::Xmu PROPERTIES
+  IMPORTED_LOCATION ${GLUT_Xmu_LIBRARY})
+  endif()
+
 endif ()
 
 find_path( GLUT_INCLUDE_DIR GL/glut.h
@@ -102,6 +135,34 @@ if (GLUT_FOUND)
 ${GLUT_cocoa_LIBRARY}
 )
 
+  if(NOT TARGET GLUT::GLUT)
+add_library(GLUT::GLUT UNKNOWN IMPORTED)
+set_target_properties(GLUT::GLUT PROPERTIES
+  INTERFACE_INCLUDE_DIRECTORIES ${GLUT_INCLUDE_DIR})
+if(GLUT_glut_LIBRARY MATCHES /([^/]+)\\.framework$)
+  set_target_properties(GLUT::GLUT PROPERTIES
+IMPORTED_LOCATION ${GLUT_glut_LIBRARY}/${CMAKE_MATCH_1})
+else()
+  set_target_properties(GLUT::GLUT PROPERTIES
+IMPORTED_LOCATION ${GLUT_glut_LIBRARY})
+endif()
+
+if(TARGET GLUT::Xmu)
+  set_property(TARGET GLUT::GLUT APPEND 
+PROPERTY INTERFACE_LINK_LIBRARIES GLUT::Xmu)
+endif()
+
+if(TARGET GLUT::Xi)
+  set_property(TARGET GLUT::GLUT APPEND 
+PROPERTY INTERFACE_LINK_LIBRARIES GLUT::Xi)
+endif()
+
+if(TARGET GLUT::Cocoa)
+  set_property(TARGET GLUT::GLUT APPEND 
+PROPERTY INTERFACE_LINK_LIBRARIES GLUT::Cocoa)
+endif()
+  endif()
+
   #The following deprecated settings are for backwards compatibility with CMake1.4
   set (GLUT_LIBRARY ${GLUT_LIBRARIES})
   set (GLUT_INCLUDE_PATH ${GLUT_INCLUDE_DIR})
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at:

Re: [cmake-developers] [PATCH 5/5] FindBoost.cmake: Add Boost::boost and Boost::C targets and documentation

2014-06-24 Thread Philipp Moeller

Stephen Kelly steve...@gmail.com writes:

 Philipp Moeller wrote:

 Stephen Kelly steve...@gmail.com writes:

 The wiki page is out of date, and so is the repo, because boost is trying
 to make a release before finishing the modularization work and it is all
 on- hold for several more months.
 
 This project has been going on for ages and considering how long it took
 Boost to change their SCM or the (stalled?) ryppl and 0install efforts I
 don't see this happening anytime soon.

 Indeed. Until a few weeks ago I believed the effort was permanently aborted. 
 Then some Boost people starting doing the modularization work, but were 
 asked to stop until after the next release (I don't know the details of that 
 reasoning). 

 After the major part of the modularization TODO is done, it would be viable 
 to start talking about whether they want to use cmake, and if not, teaching 
 bjam to create cmake config packages. 

 As you note, this is several months away. As far as I know, they want to 
 make their release in early August, but I have no idea what blocks that or 
 if it is likely that they will reach that target.

 I'm just noting all of this for informational purposes :).

 This means:

  1) Creating a Boost::boost monolithic target may not be appropriate
 
 IMO, even a modularized boost build should provide a target that just
 gives you all of the includes for convenience in addition to more
 fine-grained access, but I see why one would think otherwise.

 In a modularized system, all of boost might not be there, and the parts 
 that are might be in different places.

Sorry, poor wording on my part. I meant to say a target for all of
boost that is available. It should be easy to support includes in
different locations by just having the Boost::includes target consist of
dependencies on Boost::component_includes targets.

This is of course contrary to what modularization is supposed to
achieve, but sometimes a little convenience helps adoption a lot.

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [cmake-developers] target_compile_features remaining issues

2014-04-03 Thread Philipp Moeller

Stephen Kelly steve...@gmail.com writes:

 Hi,

 The target_compile_features topic in my clone is almost ready to merge to 
 next.
[...snipped rest of the message...]

Hi Stephen,

I'm not sure how this feature would fit in any CMake build system I
currently maintain.

How does it improve upon the current #ifdef tables provided by
e.g. Boost.Config?

How does it improve over C++14 __has_feature and __has_include?

Also, I wont be able to drop Boost.Config (or my own configuration
tables) when this feature arrives because users of my library without
CMake should still get header-files configured for their compiler.

I think this is also missing the common work-around macros
(MY_LIBRARY_CONSTEXPR, MY_LIBRARY_LIBRARY_OVERRIDE, etc.) which are
necessary to write code that works on multiple standards.

Maybe I'm missing what this feature is supposed to achieve, but I can't
see how this would serve my needs.

What I would find useful if I could use CMake to write a configuration
header with a customized prefix.

  write_compiler_configuration_header(my_lib output_path)

and the resulting header would contain the entire #ifdef for feature
availability.

Of course, when a compiler feature is a hard requirement of a target
(currently it often isn't) encoding it in the build system would be nice
to have.

Cheers,
Philipp

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [cmake-developers] target_compile_features remaining issues

2014-04-03 Thread Philipp Moeller

Stephen Kelly steve...@gmail.com writes:

 Hi,

 The target_compile_features topic in my clone is almost ready to merge to 
 next.

Hi Stephen,

I'm not sure how this feature would fit in any CMake build system I
currently maintain.

How does it improve upon the current #ifdef tables provided by
e.g. Boost.Config?

How does it improve over C++14 __has_feature and __has_include?

Also, I wont be able to drop Boost.Config (or my own configuration
tables) when this feature arrives because users of my library without
CMake should still get header-files configured for their compiler.

I think this is also missing the common work-around macros
(MY_LIBRARY_CONSTEXPR, MY_LIBRARY_LIBRARY_OVERRIDE, etc.) which are
necessary to write code that works on multiple standards.

Maybe I'm missing what this feature is supposed to achieve, but I can't
see how this would serve my needs.

What I would find useful if I could use CMake to write a configuration
header with a customized prefix.

  write_compiler_configuration_header(my_lib output_path)

and the resulting header would contain the entire #ifdef for feature
availability.

Of course, when a compiler feature is a hard requirement of a target
(currently it often isn't) encoding it in the build system would be nice
to have.

[...snipped...]


-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [cmake-developers] Exported targets with imported dependencies in CMake 3.0

2014-03-06 Thread Philipp Moeller

Jean-Christophe Fillion-Robin
jchris.filli...@kitware.com writes:

 .. and whenever possible the FindXXX.cmake should defined imported targets.

This has been another big problem I encountered while trying to fully
targetify my build system: find_package files just aren't up to speed
yet. I was thinking about making this a separate post, but I can bring
this up here as well.

It might be possible to have some general find_targets() which
essentially wraps a find_package() call and produce imported
targets. This could work for most of the general cases, but some
libraries need special-casing (Boost comes to mind, where thread has to
depend on system and as of a special version chrono, unless boost-cmake
is used, which virtually no distribution does).


 On Thu, Mar 6, 2014 at 9:38 AM, Philipp Möller bootsare...@gmail.comwrote:

 Stephen Kelly steve...@gmail.com writes:

  Philipp Möller wrote:
  It would be great, if I could export imported targets and if CMake could
  walk the dependency tree automatically and import those targets on an
  as-needed basis.
 
  Part of the problem is that the place where you import your dependent
  targets from (and the locations calculated) are not necessarily the same
 for
  your downstreams.

 I understand the issue and have been fighting it in versions prior 3.0
 as well. It also arises if you simply export targets that have been
 target_link_librarie'd against full library paths returned by a
 find_package.

 That's why I thought some build-in functionality could be helpful for
 this, e.g. exporting and imported target would lead to a definition in
 the exports file that automatically triggers a corresponding
 find_package call.

  You export your targets to and -exports file, and presumably you import
 that
  in a -config file. In the same config file, you should add code to find
 your
  dependencies too.
 
 
 http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html#creating-packages
 
  The find_dependency macro can help with forwarding some find_package
  arguments.
 
 
 http://www.cmake.org/cmake/help/v3.0/module/CMakeFindDependencyMacro.html

 The documentation is a little sparse, but I think I understand the
 purpose. I still need to traverse IMPORTED_LINK_INTERFACE_LIBRARIES and
 figure out which of the list members constitutes a target that needs to
 trigger a find_dependency and what a full library path is, correct?

 I can also not rely on a find_package call to actually produce imported
 targets and need to ship the code that turns the results of find_package
 in targets.

 Thanks for your help,
 Philipp

 --

 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

-- 

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] Exported targets with imported dependencies in CMake 3.0

2014-03-06 Thread Philipp Moeller

Stephen Kelly steve...@gmail.com writes:

 Philipp Möller wrote:

 Stephen Kelly steve...@gmail.com writes:
 
 Philipp Möller wrote:
 It would be great, if I could export imported targets and if CMake could
 walk the dependency tree automatically and import those targets on an
 as-needed basis.

 Part of the problem is that the place where you import your dependent
 targets from (and the locations calculated) are not necessarily the same
 for your downstreams.
 
 I understand the issue and have been fighting it in versions prior 3.0
 as well. It also arises if you simply export targets that have been
 target_link_librarie'd against full library paths returned by a
 find_package.

 Yes, exactly. That's the problem with having paths in 
 INTERFACE_LINK_LIBRARIES, and a good reason not to do that.

 That's why I thought some build-in functionality could be helpful for
 this, e.g. exporting and imported target would lead to a definition in
 the exports file that automatically triggers a corresponding
 find_package call.

 Seems overly-complex to implement.

 You export your targets to and -exports file, and presumably you import
 that in a -config file. In the same config file, you should add code to
 find your dependencies too.

  
 http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html#creating-packages

 The find_dependency macro can help with forwarding some find_package
 arguments.

  
 http://www.cmake.org/cmake/help/v3.0/module/CMakeFindDependencyMacro.html
 
 The documentation is a little sparse, but I think I understand the
 purpose.

 The code is easy to read, if that helps. However, it's not designed for your 
 complex case (it deliberately doesn't wrap all arguments of find_package), 
 so you may have to do something similar to it on your own.

 I still need to traverse IMPORTED_LINK_INTERFACE_LIBRARIES and
 figure out which of the list members constitutes a target that needs to
 trigger a find_dependency and what a full library path is, correct?

 No, I don't think so. You shouldn't introspect 
 IMPORTED_LINK_INTERFACE_LIBRARIES like that.

 Simply issue a find_dependency call and ensure that the package can be 
 found. That probably means writing (and shipping with your config file) a 
 Find-module for your dependency which creates the needed imported
 targets.

Some of my dependencies are chosen at configuration time, so I need to
specify somehow if a target has been build with a public dependency
enabled.

e.g. I have mylib1 and mylib2, mylib1 depends on mylib2 and optionally
on External::stuff. The classic way would be to write a variable
mylib_external_depends and go through that to trigger the appropriate
find_packages. I thought I could save myself the duplication and just
use the interface libraries instead, but you are probably right.


 I can also not rely on a find_package call to actually produce imported
 targets and need to ship the code that turns the results of find_package
 in targets.

 You can actually. You just need to write and ship such a Find-module 
 yourself (until the necessary imported targets are provided by the Find-
 module itself).

 Create a wrapper around the relevant Find-module and add the imported 
 targets.

 Something like:

  # FindFoo.cmake

  find_package(Foo PATH ${CMAKE_ROOT}/Modules NO_DEFAULT_PATH)
  add_library(Foo::Lib SHARED IMPORTED)
  # ...

 and in the config file:

  find_package(Foo ${maybe_other_args}
PATH ${CMAKE_CURRENT_LIST_DIR} NO_DEFAULT_PATH)


 If you are going to write proper IMPORTED targets for cmake-shipped Find-
 modules, I'd recommend contributing them to cmake instead anyway.

I'll see what I can do.

-- 

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] IMPORTED targets for some Find modules

Re: [cmake-developers] IMPORTED targets for some Find modules

Re: [cmake-developers] IMPORTED targets for some Find modules

Re: [cmake-developers] IMPORTED targets for some Find modules

Re: [cmake-developers] IMPORTED targets for some Find modules

Re: [cmake-developers] [PATCH 5/5] FindBoost.cmake: Add Boost::boost and Boost::C targets and documentation

Re: [cmake-developers] [PATCH 5/5] FindBoost.cmake: Add Boost::boost and Boost::C targets and documentation

Re: [cmake-developers] [PATCH 4/5] FindGLUT.cmake: Add imported targets and documentation

Re: [cmake-developers] [PATCH 5/5] FindBoost.cmake: Add Boost::boost and Boost::C targets and documentation

Re: [cmake-developers] target_compile_features remaining issues

Re: [cmake-developers] target_compile_features remaining issues

Re: [cmake-developers] Exported targets with imported dependencies in CMake 3.0

Re: [cmake-developers] Exported targets with imported dependencies in CMake 3.0

13 matches

Site Navigation

Mail list logo

Footer information