date:20140719

Re: [CMake] find_package and INTERFACE targets in 3.0

2014-07-19 Thread Hendrik Sattler

Hi,

for DLLs, the .lib part has it's own property IMPORTED_IMPLIB.

This is already the case for older versions of CMake but at least the Qt4 find
module makes no use of it.

In our own project, we use global imported targets with dll and import lib set
(and other properties like includes) and use it on Windows to copy the dlls to
the target location with a generator expression and post-build.

I guess on Windows, BundleUtilities could also be simplified if that was done
consistently.

On all platforms it's rather complicated to find out if a .lib/.so is static or
shared. IMHO this should be solved by a function that module writers can use,
either on a CMake module or integrated.
So currently, you can either guess or use UNKNOWN.

Regards,

On 19. Juli 2014 05:13:13 MESZ, Walter Gray chrysal...@gmail.com wrote:
Thanks Nils!
The examples in the git repo are particularly helpful. It seems that
in
all of the examples, the library type is being set to UNKNOWN. Is
there
a reason for this? It seems that STATIC would be more suitable for most

of those, though the wording in the docs for IMPORTED_LOCATION [1]
makes
it seem like maybe for STATIC's it's just the directory and not the
actual .lib file. I notice cmake doesn't seem to have any way to track

DLLs or dylibs. Is there some recommended way of dealing with
importing
shared libraries? The QT4 module was my best bet but it doesn't seem to

touch the .dlls at all. I tried writing some of my own for shared
libraries like SDL2, I noticed that add_libraries(SHARED IMPORTED) does

not seem to work as I expected. An example for Windows(from memory,
I'll update with the real run outputs on Monday when I'm back at the
office):

add_library(SDL2::SDL2 SHARED IMPORTED GLOBAL)
set_target_properties(SDL2::SDL2 PROPERTIES
INTERFACE_LINK_LIBRARIES
${SDL_ROOT_DIR}/lib/SDL2main.lib;${SDL_ROOT_DIR}/lib/SDL2.lib
INTERFACE_INCLUDE_DIRECTORIES ${SDL_ROOT_DIR}/include
IMPORTED_LOCATION ${SDL_ROOT_DIR}/lib/SDL2.dll
)

According to the docs for IMPORTED_LOCATION [1], for shared libraries
on
DLL platforms, it should point to the DLL part of the library. When I
add the SDL2::SDL2 to my main target, it compiles generates but when
I
run the resulting visual studio project it results in link errors with
(and this is the part I'm not sure about - again, more concrete detail
on Monday) SDL2-NOTFOUND.o and SDL2::SDL2
I suspect I'm using INTERFACE_LINK_LIBRARIES in not quite the right
way,
but those *are* the public .lib files. When I get back on Monday I'll
try a few different approaches based on what I saw in some of the
modules, namely making sub-libraries with UNKNOWN and IMPORTED_LOCATION

set for all the actual .lib files, and just directly setting
LINK_LIBRARIES

[1]
http://www.cmake.org/cmake/help/git-master/prop_tgt/IMPORTED_LOCATION.html

On 7/18/2014 5:23 AM, Nils Gladitz wrote:
On 07/18/2014 05:00 AM, Walter Gray wrote:
Hi list!

I'm a big fan of the new INTERFACE targets target usage
requirements,
but none of the provided Findpackage.cmake files seem to take
advantage of the new paradigm. Checking the wiki, the old
Findpackage.cmake seem to be deprecated, with most of the
information
on authoring new packages assuming that you are the developer of the
module, not the consumer. What is the recommended way to deal with
packages that don't provide these config files? I'll happily write
my
own Findpackage.cmake files, however that approach seems
deprecated
and I haven't found any good examples of find modules that define
IMPORT
or INTERFACE targets instead of the older method of setting a bunch
of
package_xxx variables.

There are a few modules that use imported targets in 3.0 and a few
more were updated in master.

I see e.g. FindGLUT, FindQt4, FindGTK2, FindZLIB, FindOpenGL and
FindGLEW making use of imported targets in master[1].

[2] documents how to write find modules and includes an example with
IMPORTED targets.

Nils

[1]

http://cmake.org/gitweb?p=cmake.git;a=tree;f=Modules;h=5d17682cb231f119b677ce67d804852d3be6d46f;hb=HEAD

[2]

http://www.cmake.org/cmake/help/git-master/manual/cmake-developer.7.html#find-modules

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

Re: [CMake] Package found - passing _INCLUDE_DIRS to include_directories() and _LIBRARIES to target_link_libraries()

2014-07-19 Thread Hendrik Sattler

Hi,

I'm not sure that ~ is supported directly.

HS

On 19. Juli 2014 04:31:23 MESZ, Michael Darling darli...@gmail.com wrote:
http://www.cmake.org/Wiki/CMake:How_To_Find_Libraries#How_package_finding_works

seems to indicate if PACKAGE-NAME_FOUND is found, the
PACKAGE-NAME_INCLUDE_DIRS is passed to the include_directories()
command,
and PACKAGE-NAME_LIBRARIES is passed to target_link_libraries()

Why is the reduced-case code below calling g++ without including
-I~/codeTestPackages/lib, causing a app/app.cpp:1:17: fatal error:
lib.h: No such file or directory ?

I'm on CMake v3.0.0.  Also tried CMake v3.0.20140718-g36a81 (git
source.)

All the source is below, and attached as a .tar.gz.


*### CMakeLists.txt ###*

cmake_minimum_required(VERSION 3.0)
project(codeTestPackages)
set(CMAKE_VERBOSE_MAKEFILE on)
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH}
~/codeTestPackages/findModules)
add_subdirectory(lib)
add_subdirectory(app)

*### findModules/Findlib.cmake ###*

IF(NOT lib_FOUND)
   set(lib_FOUND yes)
   message(lib_FOUND is ${lib_FOUND})
   set(lib_INCLUDE_DIRS ~/codeTestPackages/lib)
   set(lib_LIBRARIES lib)
ENDIF(NOT lib_FOUND)

*### lib/CMakeListst.txt ###*

include_directories(~/codeTestPackages/lib)
add_library(lib lib.cpp)

*### lib/lib.h ###*

#ifndef __LIB__
#define __LIB__
namespace LIB {
unsigned long libFunc(unsigned long inValue);
}
#endif

*### lib/lib.cpp ###*

#include lib.h
namespace LIB {
unsigned long libFunc(unsigned long inValue) {
   return inValue+1;
}
}

*### app/CMakeLists.txt ###*

find_package(lib REQUIRED)
add_executable(app app.cpp)

*### app/app.cpp ###*

#include lib.h
using namespace LIB;

int main() {
   unsigned long x = 1;
   unsigned long y = libFunc(x);
}




-- 

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
-- 

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

Re: [CMake] How to get a list of all the static libraries that a target will link against ?

2014-07-19 Thread Glenn Coombs

Don't all shout at once :-)  I'm guessing there are no easy solutions
then...

--
Glenn


On 28 June 2014 14:33, Glenn Coombs glenn.coo...@gmail.com wrote:

 I have a project which compiles and links into both a stand alone
 executable and a dynamic shared library.  The library and the executable
 link against the same project libraries but have different object files
 containing their entry points: main.o for the executable and dll_main.o for
 the library.  My project heirarchy looks like this (simplified a bit for
 brevity):

 CMakeLists.txt
 mtx_source/CMakeLists.txt
 mtx_wrapper/CMakeLists.txt
 testbench/CMakeLists.txt

 The top level CMakeLists.txt calls add_subdirectory on the various project
 specific library folders which each build a static library.  The testbench
 folder is the one that builds both the executable and the dynamic library.
 When building the dynamic library I need to use the linker options
 -whole-archive and -no-whole-archive to force my static project libraries
 to be included into the dynamic library. The problem is how to insert the
 -whole-archive and -no-whole-archive options so that they select the
 correct set of libraries.  Currently in the testbench CMakeLists.txt file I
 have these lines:

 set(libs
 VLC
 mvea
 ${SYSTEMC_SUPPORT_LIBRARIES}
 ${DEVIFSLAVE_LIBRARIES}
 ${SYSTEMC_LIBRARIES}
 ${SIM_UTILS_LIBRARIES}
 ${HWDEBUG_LIBRARIES}
 )

 if (NOT STUB_OUT_MTX)
 list(APPEND libs mtx_wrapper)
 endif()

 set(libs_dll ${libs} transif_slave)

 if (UNIX)
 list(INSERT libs_dll 0 -Wl,-whole-archive)
 list(APPEND libs_dll   -Wl,-no-whole-archive)
 endif()

 add_library ( csim_dll SHARED ${sources_dll} ${headers_dll} )
 add_executable( testbench   ${sources} ${headers} )

 target_link_libraries(csim_dll  ${libs_dll} ${PTHREADS_LIBRARIES} )
 target_link_libraries(testbench ${libs} ${PTHREADS_LIBRARIES} )

 which produces the following link line:

 /usr/bin/g++-4.7  -fPIC -m32  -m32 -m32 -fPIC -m32 -O3  -O3 -DHIDEBUG
 -Wl,-Bsymbolic
 -shared -Wl,-soname,libtopazhp.so
 -o libtopazhp.so
 CMakeFiles/csim_dll.dir/dll_main.cpp.o
 CMakeFiles/csim_dll.dir/main_common.cpp.o
 -lm -lrt -lm -lrt
 -Wl,-whole-archive
 ../mvea/VLC/libVLC.a
 ../mvea/libmvea.a
 ../systemCSupport/libsystemc_support.a
 ../devif_slave/libDevifSlave.a
 ../systemC/libsystemc.a
 ../sim_utils/libsim_utils.a
 ../hwdebug/libhwDebug.a
 ../mtx_wrapper/libmtx_wrapper.a
 ../transif/libtransif_slave.a
 -Wl,-no-whole-archive
 -lpthread -lz
 ../systemC/libpthreads_dummy.a
 ../external_mtx/src/external_mtx-build/metag/libmetag.a
 ../external_mtx/src/external_mtx-build/metagcopro/libmetagcopro.a
 ../external_mtx/src/external_mtx-build/metac/vmetastub/libvmetastub.a
 ../external_mtx/src/external_mtx-build/metac/insim/libinsimfpu.a
 ../external_mtx/src/external_mtx-build/mtx/insim-mtxg/libinsim-mtxg.a
 ../external_mtx/src/external_mtx-build/mtx/libmtxc.a
 -ldl -lm -lrt -lm -lrt

 The problem is that the 6 external_mtx libraries should have been included
 inside the -whole-archive section.  These libraries are specified in the
 mtx_wrapper folder with a target_link_libraries(mtx_wrapper
 ${METASIM_LIBRARIES}) command.  I have managed to wrap the direct library
 dependencies inside the -whole-archive but I need to ensure that any
 sub-dependencies are included as well (and any dependencies they might have
 recursively).  Any system dynamic libaries (-ldl -lm -lrt etc.) must appear
 after the -no-whole-archive option otherwise the link fails.  The
 mtx_wrapper library can be built in two ways and only one of them will add
 the extra METASIM libraries as a dependency, the other way fakes that code
 internally.  Adding the METASIM libraries via target_link_libraries()
 inside the mtx_wrapper CMakeLists.txt correctly handles that dependency
 when linking the standalone executable but is not working for linking the
 dynamic library.

 Is there an easy way to get cmake to handle all this ?  Is there a way to
 get a list of all the static libraries (libXXX.a) that will be included on
 the link line for a target ?

 --
 Glenn


-- 

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

Re: [CMake] Package found - passing _INCLUDE_DIRS to include_directories() and _LIBRARIES to target_link_libraries()

2014-07-19 Thread Michael Darling

I definitely want the automatic include directory adding, and also
automatic target_link_library adding.

I'm totally confused when I'd want to use an import target, and when I'd
want to use an interface target, and what a good definition is for each.  I
see interface libraries state: A primary use-case for interface libraries
is header-only libraries, and an interface target has no location and is
mutable, but is otherwise similar to an imported target.  My libraries
have separate implementation and are not header-only libraries.  But, it
says primary use-case not only for header-only libraries.

And, what's a clear definition for the difference between an import or
interface target, vs a standard statically linked library?

If it isn't too much trouble or many changes, would anyone be willing to
change the attached example to the appropriate new type of target, so the
include directories and target_link_libraries automatically propegate?  I'm
just looking to get to the point where they compile in place - not worried
about the install parts.  I think I'm getting lost without being able to
find a reduced case whole example of both the library and the applications
using it.

On Fri, Jul 18, 2014 at 11:19 PM, Walter Gray chrysal...@gmail.com wrote:

  Unless I'm mistaken, it says that the *CONVENTION* is to call
 include_directories(${PACKAGE-NAME_INCLUDE_DIRS}) manually, not that it
 is done automatically.  To get that kind of automatic include directory
 adding you need to have an import or interface target with
 INTERFACE_INCLUDE_DIRECTORIES defined by the find module, then link with
 that.  Take a look at topics related to Interface Libraries [1] and writing
 modern find modules [2]

 [1]
 http://www.cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html#interface-libraries
 [2]
 http://www.cmake.org/cmake/help/v3.0/manual/cmake-developer.7.html#find-modules


 On 7/18/2014 7:31 PM, Michael Darling wrote:


 http://www.cmake.org/Wiki/CMake:How_To_Find_Libraries#How_package_finding_works

  seems to indicate if PACKAGE-NAME_FOUND is found, the
 PACKAGE-NAME_INCLUDE_DIRS is passed to the include_directories() command,
 and PACKAGE-NAME_LIBRARIES is passed to target_link_libraries()

  Why is the reduced-case code below calling g++ without including
 -I~/codeTestPackages/lib, causing a app/app.cpp:1:17: fatal error:
 lib.h: No such file or directory ?

  I'm on CMake v3.0.0.  Also tried CMake v3.0.20140718-g36a81 (git source.)

  All the source is below, and attached as a .tar.gz.


  *### CMakeLists.txt ###*

  cmake_minimum_required(VERSION 3.0)
 project(codeTestPackages)
 set(CMAKE_VERBOSE_MAKEFILE on)
  set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH}
 ~/codeTestPackages/findModules)
  add_subdirectory(lib)
  add_subdirectory(app)

  *### findModules/Findlib.cmake ###*

  IF(NOT lib_FOUND)
set(lib_FOUND yes)
message(lib_FOUND is ${lib_FOUND})
set(lib_INCLUDE_DIRS ~/codeTestPackages/lib)
set(lib_LIBRARIES lib)
 ENDIF(NOT lib_FOUND)

  *### lib/CMakeListst.txt ###*

  include_directories(~/codeTestPackages/lib)
 add_library(lib lib.cpp)

  *### lib/lib.h ###*

  #ifndef __LIB__
 #define __LIB__
 namespace LIB {
  unsigned long libFunc(unsigned long inValue);
  }
  #endif

  *### lib/lib.cpp ###*

  #include lib.h
 namespace LIB {
  unsigned long libFunc(unsigned long inValue) {
 return inValue+1;
 }
 }

  *### app/CMakeLists.txt ###*

  find_package(lib REQUIRED)
 add_executable(app app.cpp)

  *### app/app.cpp ###*

  #include lib.h
 using namespace LIB;

  int main() {
unsigned long x = 1;
unsigned long y = libFunc(x);
 }




 --

 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

-- 

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

[Cmake-commits] CMake branch, master, updated. v3.0.0-1458-g6ae98ee

2014-07-19 Thread Kitware Robot

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.

The branch, master has been updated
   via  6ae98ee18f6c35b93556a66dc0ce909d84aec18b (commit)
  from  18a431068105c14e5b4a6d91dacac36b1f9981ef (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6ae98ee18f6c35b93556a66dc0ce909d84aec18b
commit 6ae98ee18f6c35b93556a66dc0ce909d84aec18b
Author: Kitware Robot kwro...@kitware.com
AuthorDate: Sun Jul 20 00:01:10 2014 -0400
Commit: Kitware Robot kwro...@kitware.com
CommitDate: Sun Jul 20 00:01:10 2014 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index e25559f..196832f 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 0)
-set(CMake_VERSION_PATCH 20140719)
+set(CMake_VERSION_PATCH 20140720)
 #set(CMake_VERSION_RC 1)

---

Summary of changes:
 Source/CMakeVersion.cmake |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [CMake] find_package and INTERFACE targets in 3.0

Re: [CMake] Package found - passing _INCLUDE_DIRS to include_directories() and _LIBRARIES to target_link_libraries()

Re: [CMake] How to get a list of all the static libraries that a target will link against ?

Re: [CMake] Package found - passing _INCLUDE_DIRS to include_directories() and _LIBRARIES to target_link_libraries()

[Cmake-commits] CMake branch, master, updated. v3.0.0-1458-g6ae98ee

5 matches

Site Navigation

Mail list logo

Footer information