Hendrick! That's exactly what I'm trying to do. Do you have an example of the declaration of the dll import target setup you could share? That would be immensely helpful.

Thanks
Walter

On 7/19/2014 4:01 AM, Hendrik Sattler wrote:
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,

HS


On 19. Juli 2014 05:13:13 MESZ, Walter Gray <[email protected]> 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 Find<package>.cmake files seem to take
advantage of the new paradigm.  Checking the wiki, the old
Find<package>.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 Find<package>.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

--

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

Reply via email to