[CMake] find_package and INTERFACE targets in 3.0

[Walter Gray]

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